Dave: Thank you very much for the additional information about how RB and QT work.
Initially, I used your GetWaveformInfo() routine (but modified to return 16-bit samples) to bring in the entire 53-minute mp3 audio. This created a huge memory requirement, but it was only done while testing my other algorithms. In that situation, I encountered the strange problem with the sample rates. I had to multiply the MoviePlayer Position by 43,892 to get the correct sample, and I verified this by visually matching the waveform details with the audio I was hearing. I wanted to understand why this was occurring -- hence my post to this list.
However, when I recently changed my calls to your routine to bring in 20-second chunks of the audio, I no longer had the problem. After only 20 seconds, the two rates would point to nearly the same sample anyway (only a 0.1 second difference). When brought in in its entirety, there were 15 seconds of "dead" samples at the end, but the total of all the zero samples at the end of each chunk was considerably less than 15 seconds worth of audio. So, I believe 44,1000 is the correct rate for both the RB player and the samples, at least when chunking. But, I am not certain.
I do not know how to determine if an mp3 is VBR -- the info in QT Player says only 44,100 Hz. However, I would expect the OS calls your routine used to produce 44,100 samples per second if they also report a 44,100 Hz rate (which they do).
To answer your question, I am using the duration information to scale a waveform overlay that has markers at certain points in time, so I need to know the actual duration of the waveform. When I was loading all the samples en masse, I also needed the durations to compute the effective sample rate (according to the formula I posted a few days ago that related the three domains).
One lingering issue is that while your routine is executing, my GUI is locked up. I am using a thread at very low priority, but when an OS routine is running, apparently none of the the RB threads run, even the main thread. By using small chunks, I can minimize this effect. FYI, on my iMac G5 (2 GHz), your GetWaveformInfo() routine consumes 42 milliseconds (overhead) plus 16 milliseconds per second of audio samples retrieved (using 16-bit samples). So, the time to fetch a 20-second chunk is about 362 milliseconds.
I appreciate your help and thank you for making GetWavefromInfo() available. Jeff
Hi Jeffrey, Some thoughts: iTunes doesn't use QuickTime for playback, at least not in the way that any other application does. As far as I know, REALbasic is just wrapping the QuickTime API in some REALbasic objects and the MoviePlayer control. I'd doubt that the RB MoviePlayer is using a sample rate of 43,892 kHz. It's more likely that the endpoint is being calculated incorrectly in some cases, or is being estimated by QuickTime when opened. The sample code I posted (IIRC) actually extracts the audio - i.e., works through the entire file and converts the encoded MP3 track into raw samples - so once it's done, you would have the true number of samples from the file. Out of interest, is the MP3 in question a VBR (Variable Bit Rate) MP3? If so, that might explain why only certain MP3s (from Bruce) have this problem. The QuickTime MP3 importer isn't a big fan of VBR files, and this might be the source of the inconsistencies. I could believe that for a long VBR, QuickTime might estimate the length inaccurately. I guess my other question would be, what are you looking to use the duration info for? Dave.
_______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
