Different Duration-Lengths

Hey PG,

I am having a folder called ‘Finalized’ - with 24 Bit-Files.
From this folder I do Batch-Conversion in all other formats (MP3/Flac/16 Bit).

What I noticed is that when I look into the details of the folder the resulting information differs i.e.

Finalized (Source):
24 Bit: Duration 11h 55min 18sek.

Batched (Result):
MP3: Duration 11h 54min 19sek.

Where does that come from?


What mp3 codec settings do you use?

What is strange, is that your .wav screenshot shows ‘multiple values’ as bitrate. I’ve never seen that for .wav, and was expecting something like that for a VBR MP3 - which in your other screenshot shows 192 kbps. I would ask, what type of .wav is this?

Open the MP3 in MP3 Diags and it should tell you what’s wrong.

I guess you encode to mp3 VBR. In that case, since there is no index table, the length is just a guess based on the first mp3 frames.

I don’t think it’s VBR PG. VBR would probably be even further off. I think the long file is probably 128 CBR, and still time is misreported by Windows Explorer even in Windows 10. And probably by Mac Finder. Testing, I also get incorrect times in Explorer and Mac Finder with Wavelab FR 128 CBR with long files. The MP3 is reported 5 seconds shorter than the WAV for a 36 minute file.

It goes back to this:

It needs to be corrected in Wavelab (just like the VBR problem with all Wavelab VBR MP3), because it doesn’t happen with MP3s made by other programs like iTunes.

Hey PG,

The different Bitrates are a result of the first and the last Tracks (Intro with music) being stereo, while all others are Mono.

I am encoding to 192 kbps - NOT using VBR.


Can you look at the values with VLC? Your pictures seems to come from Windows, which is not a good reference for such reports.

The file time appears correct when opened normally in VLC. The file time appears incorrect when added to a VLC Playlist (until the file is played), and that is not as it should be.

But all of this is beside the point, because MP3s are for clients and they should appear and play correctly no matter where the client views or plays them. ALL other program’s MP3 times appear correct in Windows Explorer and Mac Finder, as they should. And Wavelab MP3s should too, so this should be fixed as it is in other programs. The long file CBR timing problem is with Wavelab Fraunhofer CBR. Doesn’t seem to happen with Wavelab LAME CBR here.

The worse problem is the VBR problems, because Wavelab is the ONLY program making VBR MP3 anymore that doesn’t use VBR headers, so times are misreported in many situations, and player playhead behavior is adversely affected, which makes absolutely no sense coming out of a mastering program where clients are sent MP3 files.

btw, for this long file FH CBR timing problem, the time is misreported in Mac Finder exactly as it is misreported in Windows Explorer.

Bumping this up, since the problem still exists.

Did you think of activating this option when encoding to mp3?

No, I didnt. I dont use VBR - should it be activated anyway?
…and I accidently posted this in the WL9 Board - it also applies to WL10.