.wav file durations in .cue file

[glennl]

So the primary answer at http://stackoverflow.com/questions/7833807/get-wav-file-length-or-duration/7842081#7842081 describes a technique for getting the duration of a .wav file in Python, my favorite programming language these days.

 

I note that when adding .wav files to a .cue sheet in ImgBurn, that it produces lines such as:

 

FILE "a01.wav" WAVE

REM FILE-DECODED-SIZE 03:04:21

TRACK 01 AUDIO

INDEX 01 00:00:00

 

It seems plausible that the second line of that is ImgBurn's estimate of the audio duration of the .wav file.

 

Yet the Python technique produces 03:04:27 (well, it produces a floating point number of seconds, but I changed the technique slightly to use all integer arithmetic, and produce the MM:SS:HH format output) for that same .wav file. Testing about 10 .wav files, the Python technique always produces a number slightly larger than ImgBurn.

 

How does ImgBurn calculate the duration? Or how is it different than what the Python technique does?

 

Is the REM FILE-DECODED-SIZE actually used by the burn process, or is it ignored, with ImgBurn recalculating the the length from the actual file it is given?

 

I care, because I'm starting to write a program to pull together various sources of metadata, and make my own .cue files to feed to ImgBurn, and I'd like my numbers to match. They are close enough, if ImgBurn ignores the number in the .cue file, of course, as it is within a few hundreths of a second.

[glennl]

Fiddling around a bit more, I noticed that PREGAP is given in frames that are 75 frames per second. So even though the sample rate is 44100, and not all .wav files are an even multiple of frames, the ImgBurn FILE-DECODED-SIZE seems to be the duration in terms of MM:SS:FF (MM - minutes, SS - seconds, FF - frames at a framerate of 75/second), and any fractional frame is rounded up. Now I can produce exactly the same numbers as ImgBurn.

 

If you have knowledge of why these particular numbers are used, rather than the sample rate or something else, it would satisfy my curiosity. Meantime, I guess I have enough information to do what I need to do, and it is now documented for others that might search.

 

Here's the python source:

 

filename = 'a01.wav'

import wave, contextlib

with contextlib.closing( wave.open( filename, 'r')) as f:

frames = f.getnframes()

rate = f.getframerate()

framerate = rate / 75

duration = ( frames + framerate -1 ) / framerate

frames = duration % 75

secs = ( duration / 75 ) % 60

mins = duration / ( 60 * 75 )

print("%2.2d:%2.2d:%2.2d" % ( mins, secs, frames ))

[glennl]

Well, the indentation didn't go through right. One cannot be an expert in the use of every forum. Lines after "with" in the Python source should be indented one more level, folks.

[LIGHTNING UK!]

1 frame is 1 sector and that's just how CD (CD-DA) times get listed. You can't burn part of a sector, it's all or nothing, hence the rounding.

[glennl]

Thanks for the explanation of where the numbers come from. I could reproduce them, but didn't understand them fully.

 

Well, yes, I can see where burning a partial sector would not work. One could speculate about merging multiple tracks prior to burning to avoid leaving unwanted silence for less than a 75th of a second, but it is not clear how useful that would be I did note that the WavTrim application has an option to ensure that the trimmed .wav files in produced are exact sector boundaries, and this also explains its reasoning.