Wavelab VBR MP3's - lack of VBR header

This goes back to at least one earlier thread in Wavelab 8, but the issue still exists in Wavelab 9.

It would seem that Wavelab is probably the only program that still makes VBR MP3s (both Fraunhofer and LAME) that are not identified as VBR by two of the only programs that identify CBR vs VBR: Foobar2000 and xRecode. In these programs, Wavelab VBR MP3s are identified as CBR. And Wavelab’s Frauhofer VBR MP3s are also oftentimes displayed with incorrect times in iTunes and Foobar2000 players, which messes up the playhead in those players. (the time discrepancy is what prompted the Wavelab 8 thread). In VLC Playlists (a program PG mentioned in the Wavelab 8 thread), Fraunhofer times are also often initially wrong, and only become right as each file is played. No other program I find besides Wavelab makes VBR MP3’s that are not identified correctly or have time problems like this.

The Wavelab VBRs can be fixed with the “fix VBR mp3 header” tool in Foobar2000 (see first attached pic), but one shouldn’t have to do this.

I have example files: 11-14 second Wavelab Fraunhofer VBR files that are seen as 3 seconds in iTunes (partially) and Foobar2000. The mistimes in players only seem to happen with Wavelab Fraunhofer, and only sometimes. Wavelab LAME only seemed to have problems with OS times in the earlier thread. But Wavelab is still the only program that makes MP3 VBR files that exhibit these issues at all from what I can tell. (the other encoding programs I’ve tried being iTunes MP3, XLD LAME, Sonnox Fraunhofer, Foobar LAME, xRecode LAME. VBR MP3s made in all these programs are correctly indicated as VBR in the other players, with correct times).

as a note, fixing the VBR header in Foobar doesn’t fix the clicks that occur in Wavelab continuous lossy file transitions. That’s still a different issue.

But the lack of VBR headers in the Wavelab files when all others seem to have added it by now, should be addressed.
Foobar before vbr header fix.png
Foobar after vbr header fix.png
iTunes before vbr header fix.png

last pic.

Having just discovered the MP3 Diags program, I took some screenshots of Wavelab Fraunhofer and Wavelab LAME VBR MP3’s, and the xRecode LAME VBR MP3.

The Wavelab files are the only ones in the list that don’t have XING headers (except the Sonnox which has VBRI header, and the WMP file which is CBR. The program says Sonnox should switch to XING from VBRI because it’s more compatible).

xRecode MP3s also happen to play continuous seamless in iTunes and Foobar player, but not necessarily because of this.

Thats the reason I only export to wav in wavelab and do all things MP3 in foobar2000.
Its really sad that one have to use a free external programm instead of the expensive programm one has bought for audio editing.

But I already know how this ends: “No fault in Wavelab, we make everything right, the other programms are faulty”

Thanks so much for the comment folkfreak, I fully agree.

PG, is the reason Wavelab doesn’t add the VBR header for simplicity of the files and to let the players take care of this? After seeing how VLC deals with the playlist (doing the calculations and displaying the correct time only after the file is put into play?). I could see that as a reason to leave it to the players, but everybody else adds the VBR header when making the files, and iTunes (and the other players) don’t deal with the files as VLC appears to, so iTunes and the others will continue to display the wrong times and the playhead will be wrongly affected. I don’t think Apple or any of the other player makers are going to change to accommodate Wavelab VBR files if everybody else is adding headers when making the files. So could Wavelab please add the header?

But I already know how this ends: “No fault in Wavelab, we make everything right, the other programms are faulty”

I never said that on that topic. I also think this VBR table option should be added in the future.
This option was long postponed, because a long time ago, CBR was generally preferred over VBR for player compatibility reasons. But today this argument does not stand anymore.


Any estimate on when for this PG? Wavelab is still the only program I know that makes VBR MP3 without VBR headers, so I personally wouldn’t make a VBR MP3 in Wavelab until it does.

Sorry, I don’t know yet when this comes. But this is on my tablets.

PG, do you have any idea when this might be going in? I just made an 80 min MP3, trying both Fraunhofer and LAME. Windows Explorer says the Fraunhofer is 5 hr 1 min, and the LAME is 4 hr 20 min. iTunes got the LAME right, but says the Fraunhofer is 8 hr 50 min.

In next WaveLab, the Fraunhofer will have a VBR header, as an option (‘on’ by default). You won’t have to wait too long.

Thanks PG, that’s great. I hope the LAME is done at some point because LAME vbr song times are way off in Windows Explorer and Mac Finder. Although I haven’t tried latest Mac OS.

Sorry, no short-time plan for LAME.

I hope you reconsider PG. Wavelab is the only program making VBR MP3s using LAME (or any other codec) that doesn’t use VBR headers, for many years now. In 2017 I would consider this a bug. A new user has no warning this will happen until they get a complaint from a client, or do specific testing that shouldn’t be necessary. There should be a big warning, or the LAME VBR should be disabled, or something at least. Really it should just be fixed, just like all other programs fixed it years ago.

As mentioned, this will be supported by the Fraunhofer encoder, which is a high quality encoder.
IOW, there will be a solution.

But still no warning for the new Wavelab user using LAME VBR and expecting it to work as in other programs, with times correct in Finder and Explorer. If VBR headers are not going to be added to LAME, like they are in all other programs using LAME (and any other codec), there should at least be a big warning given to new users. At the very least.

If every other program in the world can put VBR header in LAME, why can’t Wavelab?

It’s just a matter of where to put development priorities. Fraunhofer was the priority over Lame. And having a solution is already good.