Hi, So you're saying the bottom line is that it has to be within the 2GB limit? It's only a 232MB MP3 file, so to me, that should still be usable. Also, I've received files like this before with no issues of CD-quality and 44.1KHZ sample rate. Or maybe I'm just being dense. *smiles*
Regards, Nic Slau Halatyn wrote: > One thing to consider regarding file formats is the bit depth. In the case of > a CD-quality file, it's 16 bits. The sampling rate is fairly meaningless > especially when it comes to compressed formats like mp3. One must then > consider the compression ratio. for normal AIF and WAV formats, a 16-bit > 44.1/48 kHz file is roughly 10 MB per stereo minute whereas a compressed > format can be as little as one tenth the size. Higher quality 24-bit files > are 50 percent larger at 15 MB per stereo minute. Ultimately, the file size > itself needs to be within the 2 GB limit to be useable. I think that's > changed in 64-bit systems though. I'll have to double check. > > Slau > On Mar 12, 2010, at 4:52 PM, Nicolai Svendsen wrote: > > > Hi, > > > > Definitely a good post, thank you. > > > > I was pondering that possibility, though I had a look at two similar files, > > one longer than the first. I have a six hour long file, encoded with > > 44.100KHZ. That file worked perfectly. Just the way it was supposed to work. > > > > Then I had a look at the four hour long audio file. Exactly same format and > > sample rate. > > > > So I wrote to the list. I'm still a bit confused as to why it won't, as I > > have an even longer file at exactly the same quality that works just fine. > > > > If you take the audio file at six hours, encoded with a 44100KHZ sample > > rate. That's just about 952560000 seconds, or just about. Then take the > > four hour long audio file, encoded again at 44100KHZ. That's about > > 635040000 seconds. That unfortunately doesn't seem to be the problem. What > > else might be causing this? It doesn't even come close to the 2000000000 > > mark. Only halfway. > > > > Thank you for the in-depth suggestion, though. :) > > > > Let me know if I'm understanding this right. > > > > Regards, > > Nic > > Skype: Kvalme > > MSN Messenger: nico...@home3.gvdnet.dk > > AIM: cincinster > > yahoo Messenger: cin368 > > Facebook Profile > > My Twitter > > > > On Mar 12, 2010, at 10:14 PM, Esther wrote: > > > >> Hi Nic, > >> > >> The problem of the maximum time for working with an audio file is not > >> specific to iTunes. Basically none of the music programs, including > >> QuickTime, can correctly handle sound files where the number of samples > >> exceeds 2 billion (or, to be precise, the maximum number that can be > >> represented with a 32-bit unsigned integer, or 2 raised to the exponent of > >> 31, which is about 2.1478 billion samples). One of the numbers in the > >> file header for the audio file is a counter that turns over when you > >> exceed this maximum. This means that the actual maximum file length (in > >> time) that can be correctly read from these audio files depends on the > >> quality of the file encoding. CD quality music files sample the music at > >> 44.1 kHz (44.1 thousand samples per second). Voice memo files might > >> sample at 8 kHz (8 thousand samples per second) -- a rate that is more > >> than 5 times smaller. The total number of samples is the encoding sample > >> rate (e.g. 44.1 kHz for a CD) multiplied by the time of your audio file in > >> seconds. This number hits the 2 billion maximum for a file length of 13.5 > >> hours, assuming this is stereo music. This is an absolute maximum that > >> the file structure can correctly represent -- you can still run into > >> problems before this. When music programs like QuickTime or any > >> comparable programs on any platform (Windows, Linux, Mac, etc.) read these > >> files, they all compute the time from the number of samples, and they all > >> get incorrect answers when the counter is exceeded. That's why you're > >> able to play the files with QuickLook, which just starts streaming without > >> trying to read the time. The exact wrong number depends on the rollover > >> value of the counter. > >> > >> Moreover, if you think back to recent posts by James looking for the intro > >> and other music files that the Mac plays on startup, you'll notice that > >> the file extensions are .caf instead of .aiff (Audio Interchange File > >> Format). The new format is "Core Audio File Format", and one of the > >> reasons for the new file format is that these files can correctly > >> represent samples that exceed the 2 billion counter maximum. > >> > >> All of this comes up in discussions of the maximum length you can make a > >> single audiobook file and play it correctly. > >> > >> HTH. You can get longer files to play, and get correct times if you > >> reduce the audio quality. > >> > >> Cheers, > >> > >> Esther > >> > >> > >> Nicolai Svendsen wrote: > >> > >>> Hi guys, > >>> > >>> I sometimes get really huge audio files, sometimes files that last more > >>> than eight hours in length. The problem is this. > >>> > >>> While iTunes can actually measure the time properly, it won't play it > >>> all. I have a file which is nine hours long, but it will only play two > >>> hours of it. The LCD just stops counting, even though it shows that seven > >>> hours are left of the total time. If I use Quick Look, I can go to 100 > >>> percent of the file, where iTunes will usually cut it off. However, if I > >>> leave it to continue in Quick Look, what will actually happen is that it > >>> will go beyond 100 percent because the file is longer than it thinks, > >>> even though it actually measures the time properly. I played a similar > >>> file earlier today, and it hit 405 percent before it finished, however if > >>> I stopped playback or attempted to go backwards, it'd put me back at > >>> where it cut off. > >>> > >>> If anyone can help, I'd appreciate it. And please, don't come with > >>> useless comments like "Your iTunes is broken". I know for a fact that it > >>> is not, because I just reinstalled out of interest. When I figured out > >>> that wasn't the problem, I just reverted the changes. > >>> > >>> Thanks in advance. :) > >>> > >>> Regards, > >>> Nic > >>> Skype: Kvalme > >>> MSN Messenger: nico...@home3.gvdnet.dk > >>> AIM: cincinster > >>> yahoo Messenger: cin368 > >>> Facebook Profile > >>> My Twitter > >>> > >>> > >> > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "MacVisionaries" group. > >> To post to this group, send email to macvisionar...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> macvisionaries+unsubscr...@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/macvisionaries?hl=en. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "MacVisionaries" group. > > To post to this group, send email to macvisionar...@googlegroups.com. > > To unsubscribe from this group, send email to > > macvisionaries+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/macvisionaries?hl=en. -- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To post to this group, send email to macvisionar...@googlegroups.com. To unsubscribe from this group, send email to macvisionaries+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/macvisionaries?hl=en.
