Phil Freihofner wrote:I dont' think that will work for MP3 files. I cannot find the length in frames, and there is no indication of bytes per frame. I don't think it's constant throughout the MP3 file.
If you have the sample size (i.e., the length in frames) and the number of bytes per frame, you can get an exact number of bytes by multiplying these numbers, yes?
For example, if 16 bits encoding, stereo, then multiply the number of frames (sample size) * 2 bytes per sample * 2 channels per frame. The exact time can be determined from that by using the sample rate.That works for WAV files, but not MP3 (AFAIK)
AudioInputStream has a .getFrameLength method. The JavaZoom ogg/vorbis decoder I was using also had this method. I would guess the JavaZoom mp3 decoder also has a getFrameLength method.Yes, it does support that method (I think it is required if the MP3SPI implementation is to suppor the required interfaces. However, that method "reliably" returns a value of -1 (as do getSampleSize() and getFrameSize()).
I wouldn't trust the info in the metadata. Isn't that often entered by the consumer? Also, I believe that the wav file format's header can vary in size (in part due to the metadata itself). It's better to rely on code that has already been built to parse wavs.Absolutely agreed. That's why I'm looking for a more reliable method. I think I can calculate an estimate (but would prefer a precise value) of the decoded audio length as long as the bitrate property is always present and correct. I'm not sure if I can rely on that being true, though. I'm not sure if the bitrate property value itself is an estimate or precise value, or if it remains constant throughout the file. And I don't know if it includes the bits present in the frame headers or just the frame payload (audio).