If — as pretty much everyone, including the link-rot prone Boston Globe predicts — Apple announces an online music service at their press conference this afternoon, they may be on the right track. But 99 cents per track is still too much to pay for music in the lossy MP3 format, without packaging, when the recording industry bears no inventory cost, and especially if (as reported) the scheme includes limitations on copying.
What the industry needs to catch onto is that a low-cost, high-quality file sales program itself drives out “piracy.” At, say, 25 cents per selection, it’s simply not worth my time to seek out a copy of the New England Blues Prophets’ version of “Caledonia,” download it (possibly several times, allowing for dropped connections), find out that it’s a poor encoding or a Madonna-style spoof, or not even the selection I had been looking for (P2P file labelers are notoriously sloppy). Even at minimum wage, my time is worth more than that. The problem, I suppose, is that I might download the Blues Prophets’ Greatest Hits for 25 cents apiece, and re-sell them online for ten cents each. But I couldn’t do it above the table; buyers would be highly vulnerable to fraud; it would require the buyers’ seeking out unadvertised distributors (publicly advertising this resale would fall under extant copyright restrictions unless the sellers could demonstrate that they had paid the requisite licensing fees). Why put the time into tracking down Sleazy Al’s House o’ MP3s to see whether he has bootlegs of Lou Reed if you can simply go to www.loureed.com and download his latest songs directly?
So, props to Apple for pushing the music recording-and-packaging industry toward the tracks, but they’re not on the clue train yet. I’m dubious about the success of this venture till someone cuts the prices.
[After the announcement] OK, Apple got right the question of limitations on copying, and I haven’t compared MPEG-4 with MP3, so I’ll give them the benefit of the doubt on the question of sound quality. The price is still too high, but the rest of the venture looks intriguing. I’ll download iTunes 4 and report back.
Posted by AKMA at April 28, 2003 10:16 AM | TrackBackThese secret identities serve a variety of purposes, and they help us to understand how variables work. In this lesson, we'll be writing a little less code than we've done in previous articles, but we'll be taking a detailed look at how variables live and work.
Posted by: Mable at January 13, 2004 04:34 AMSince the Heap has no definite rules as to where it will create space for you, there must be some way of figuring out where your new space is. And the answer is, simply enough, addressing. When you create new space in the heap to hold your data, you get back an address that tells you where your new space is, so your bits can move in. This address is called a Pointer, and it's really just a hexadecimal number that points to a location in the heap. Since it's really just a number, it can be stored quite nicely into a variable.
Posted by: Melchior at January 13, 2004 11:03 AMThat gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.
Posted by: Prospero at January 13, 2004 11:04 AMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Court at January 13, 2004 11:04 AM