I think the reason people are so bummed about the 32,000 limit is because iTunes is so awesome in every other respect. I haven't reached 32,000 yet, but i probably will at some point. And the thing that really sucks about it is that iTunes has been good enough to keep any serious MP3 player competition out of the way. I've tried all of the competitors, and they seem okay - but nothing really matches the interface of iTunes on any platform that I've seen. I don't think that iTunes have limitations that stop people with large collections from enjoying it. If you remember the TV commercials for iTunes, they featured actually cool musicians. Apple's fan base is definitely populated by lots of serious music fans, and I think they should address this issue in a future update.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iTunes 32k Limit
- Thread starter MacRumors
- Start date
- Sort by reaction score
32,000 songs, about $40k worth of music. That's a very expensive hobby, (or at least it soon will be since you posted on macrumors). Thats interesting to note that Itunes for Mac OS X has a limit.
Personally, itunes is fine. I have bose speakers and Sennheiser headphones I run the music through and it sounds great. I usually don't rip anything over 192 since 99% of all cd's aren't over 160 unless they are Singles. The only time I have had any problems is with some classical songs that have a lot of symbols and a lot of range, and ripping at a constant 256 is fine.
It sounds good, and even lame I haven't noticed a difference, and I jsut like iTunes interface. very simple and clean.
Plus, Super CD and ADVD is a waste of money and a trick for us to buy heavily encrypted music.
I had a friend who is an audio fiend praise for the fact that he could here the wisp of of the symbols in some classical music on his Super CDs. Yay, I want to here musicians breathe in my music more than I already can
VIVA MP3!!!!
It sounds good, and even lame I haven't noticed a difference, and I jsut like iTunes interface. very simple and clean.
Plus, Super CD and ADVD is a waste of money and a trick for us to buy heavily encrypted music.
I had a friend who is an audio fiend praise for the fact that he could here the wisp of of the symbols in some classical music on his Super CDs. Yay, I want to here musicians breathe in my music more than I already can
VIVA MP3!!!!
No database limit
The 32000 entries is a limit of the Carbon Listmanager. (It uses the 'short' datatype for the number of rows.)
So I suppose it has nothing to do with the database itself.
Maybe Apple will move to a Cocoa based UI sometime; that would overcome this limitation.
bye. Andreas.
The 32000 entries is a limit of the Carbon Listmanager. (It uses the 'short' datatype for the number of rows.)
So I suppose it has nothing to do with the database itself.
Maybe Apple will move to a Cocoa based UI sometime; that would overcome this limitation.
bye. Andreas.
VBR or CBR? I import at 160 k VBR, joint stereo, and that seems to work really well and keep the file size down.
32,000 songs really is ridiculous. I'm sure s/he paid for all those and personally spent god-knows-how-many hours ripping each and every song.
Not.
No sympathy here.
i dunno, i would imagine you could get much of that music for free online (not everyone charges out the arse for their art), and from used CDs, and so on... of course, he probably did cheat, but i wouldn't say that 32000 songs = $40k just like that. that's if you pay 16 dollars for every CD you ever buy.
not true i have more than twice that much music and the most i probably spent to get the CDs isn't even enough to buy a comp.
how? do you spend 10 cents a CD or what? at an average of 12 tracks per CD, that's about 5300 CDs you have, so you would have to average less than, what, .40$ a CD to have spent less than the value of a computer on your CD collection...
I noticed somewhere somebody mentioned that iTunes is not altivec enhanced for playback, and was wondering if someone could tell me what player would be, or if this statement was even true to begin with
personally, i'd be surprised if it was, though that's not based on any real knowledge. there's nothing inherent in an mp3 that makes it work better under G4, but i couldn't tell you about apple's own decoder.
It is a hell of alot cheaper than Oracle. It is not vulnerable to MS SQL worms. I am not sure about its pros and cons, but I do know that my officemate has written a few cool apps that rely on mySQL for a database:
http://www.net.cmu.edu/netreg/
It is a web app that allows any user on campus to register their computer's mac address, get a static (or dynamic) ip address. Pick their own hostname, write out dns and dhcp config files, maintain ddns zone files. mySQL works quite well with this function.
If Apple wanted to use mySQL as a database for some feature, why would they care about foreign keys anyway?
Songs
Hey, I have 6 gigs of music....1400 songs, all my own CD's...I spent hours ripping them, tagging old ones I didn't tag originally, and organizing them.....I have a favorites playlist of about 200 plus songs...and I just installed a new car stereo with an MP# player input that I use my iPod with. All works and sounds great, EXCEPT my car just died 8-(.
Hey, I have 6 gigs of music....1400 songs, all my own CD's...I spent hours ripping them, tagging old ones I didn't tag originally, and organizing them.....I have a favorites playlist of about 200 plus songs...and I just installed a new car stereo with an MP# player input that I use my iPod with. All works and sounds great, EXCEPT my car just died 8-(.
someone asked which is the best filesharing program for Mac. it is Acquisition. you can get it at Versiontracker and probably other places too. it's nice not to have to put up with the slowness and crashiness of Limewire anymore.
wow. are they legal? how many total albums is that (assuming they are all your own full ripped CDs)?
Okay, "32000" comes from using a short-indexed list (max for a signed short is 32,768; some implementations of such lists might "cap" themselves at 32000 just for an easier-to-remember number in the docs).
Why not an "unsigned" index? Generally signed values are used when the list is not likely to expand beyond the signed-16-bit limit in any case, thus allowing a programmer to use the 16th bit (the sign) as an error flag (ie, return -1 on error instead of an index in the array, etc). There are certainly different ways to do this (most obviously use a separate field altogether for the error indicator), but the signed-bit error indicator is the most efficient design pattern by far. And though it cuts the overall list max size in half (from 64k to 32k), when your design parameters don't even touch 32k it is wholly acceptible to trade unused capacity for efficiency.
Why not a larger (32-bit) int instead of 16 bit signed shorts? Because (1), again, 32000 is one hell of a lot of songs - far more than iTunes was designed to handle - and such a limitation is thoroughly understandable in a consumer music library app, and (2) a larger index inflates the memory usage requirements of the application and slightly complicates the API, which in turn makes the app slower and more memory-intensive for the 99% of us who don't have or even want 32,000+ songs in our libraries.
Why not a database? Because that's pure overkill. iTunes can keep a lot of its information in memory (another reason to have hard limits on library size), with little-to-no overhead as one would see with a database back-end. Granted, there are also arguments for a database, including allowing other apps to see the iTunes information (the xml file is fairly easy to parse if you need to, though it assumes an order-preserving XML parser which isn't exactly standard-compliant although almost all XML parser libraries are order-preserving), but a database-backed client application is an order of magnitude more complicated to design and implement than one that can hold the vast majority of its book-keeping data in-memory at all times.
Finally, someone said that it would be "easy" to just use unsigned 32-bit ints instead. Well, no. See the arguments above as for why you wouldn't want to do that in the first place, and then consider that the cost of moving to a wider index now is quite expensive. You would likely have to use different underlying list classes, and any place where you are holding an in-memory index (32000 bytes isn't a lot of memory to just hold in RAM) you now have to reconsider (because 2GB of memory is!). This is far from "simple" This is a redesign and rewrite of the data management code.
People. Cars aren't designed to operate at 500MPH because design involves compromises (and I doubt most of us would really enjoy taking the kids to school strapped on the spoiler of an F1 racer, right?) Design is, by its nature, a study of compromises. iTunes is not designed to operate on 15 billion songs. That design imperative extends from the UI paradigms involved (playlists and such are a poor interface for mega-libraries of music) to the underlying data structures (what we are seeing here most likely). If you need more than 32000 songs then you should purchase a product designed for that, and recognize that its interface will likely be quite different from that of iTunes. iTunes is designed to be easy-to-use, clean, and fairly efficient for managing and playing a consumer-sized library of songs (yes, more like 1000-5000 songs max than 32000).
For a 1-5k library managing system, iTunes appears quite well designed. It has a significant (~10x) growth room for 95+% of us, while retaining the most efficient underlying methods possible.
For the record, my iTunes library is 1115 songs, of which I'd sideline (burn MP3s to CD or DVD and archive them) probably 300-400 if space were ever needed. My library takes 5.28GB on disk, ~4.74MB/song, which would put 32000 songs at about 152 GB. I definitely won't be allocating that much hard drive space to iTunes in the semi-near-term future either.
Why not an "unsigned" index? Generally signed values are used when the list is not likely to expand beyond the signed-16-bit limit in any case, thus allowing a programmer to use the 16th bit (the sign) as an error flag (ie, return -1 on error instead of an index in the array, etc). There are certainly different ways to do this (most obviously use a separate field altogether for the error indicator), but the signed-bit error indicator is the most efficient design pattern by far. And though it cuts the overall list max size in half (from 64k to 32k), when your design parameters don't even touch 32k it is wholly acceptible to trade unused capacity for efficiency.
Why not a larger (32-bit) int instead of 16 bit signed shorts? Because (1), again, 32000 is one hell of a lot of songs - far more than iTunes was designed to handle - and such a limitation is thoroughly understandable in a consumer music library app, and (2) a larger index inflates the memory usage requirements of the application and slightly complicates the API, which in turn makes the app slower and more memory-intensive for the 99% of us who don't have or even want 32,000+ songs in our libraries.
Why not a database? Because that's pure overkill. iTunes can keep a lot of its information in memory (another reason to have hard limits on library size), with little-to-no overhead as one would see with a database back-end. Granted, there are also arguments for a database, including allowing other apps to see the iTunes information (the xml file is fairly easy to parse if you need to, though it assumes an order-preserving XML parser which isn't exactly standard-compliant although almost all XML parser libraries are order-preserving), but a database-backed client application is an order of magnitude more complicated to design and implement than one that can hold the vast majority of its book-keeping data in-memory at all times.
Finally, someone said that it would be "easy" to just use unsigned 32-bit ints instead. Well, no. See the arguments above as for why you wouldn't want to do that in the first place, and then consider that the cost of moving to a wider index now is quite expensive. You would likely have to use different underlying list classes, and any place where you are holding an in-memory index (32000 bytes isn't a lot of memory to just hold in RAM) you now have to reconsider (because 2GB of memory is!). This is far from "simple" This is a redesign and rewrite of the data management code.
People. Cars aren't designed to operate at 500MPH because design involves compromises (and I doubt most of us would really enjoy taking the kids to school strapped on the spoiler of an F1 racer, right?) Design is, by its nature, a study of compromises. iTunes is not designed to operate on 15 billion songs. That design imperative extends from the UI paradigms involved (playlists and such are a poor interface for mega-libraries of music) to the underlying data structures (what we are seeing here most likely). If you need more than 32000 songs then you should purchase a product designed for that, and recognize that its interface will likely be quite different from that of iTunes. iTunes is designed to be easy-to-use, clean, and fairly efficient for managing and playing a consumer-sized library of songs (yes, more like 1000-5000 songs max than 32000).
For a 1-5k library managing system, iTunes appears quite well designed. It has a significant (~10x) growth room for 95+% of us, while retaining the most efficient underlying methods possible.
For the record, my iTunes library is 1115 songs, of which I'd sideline (burn MP3s to CD or DVD and archive them) probably 300-400 if space were ever needed. My library takes 5.28GB on disk, ~4.74MB/song, which would put 32000 songs at about 152 GB. I definitely won't be allocating that much hard drive space to iTunes in the semi-near-term future either.