Updating LAME codec

All topics on WaveLab 9 and WaveLab Elements 9
AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Updating LAME codec

Post by AlexBarton » Wed Jan 23, 2019 8:29 pm

Hi all,

longtime user of wavelab here, currently on WL9.5, i'm looking to update the LAME codec,
im getting sync issues with wav's i generate at the same time, (mp3's are 7 seconds longer than the wav's over a 26hr length (audiobooks)
whereas if i batch convert the wav's I've generated in reaper, using the later LAME codec (3.99.5) all is well,

can anyone help? i'm mac based and cannot seem to find a later libmp3lame.dylib that will work correctly. when i insert it into the system folder (OSX.13.6)

thanks!

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Thu Jan 24, 2019 6:30 am

AlexBarton wrote:
Wed Jan 23, 2019 8:29 pm
can anyone help? i'm mac based and cannot seem to find a later libmp3lame.dylib that will work correctly. when i insert it into the system folder (OSX.13.6)thanks!
Maybe Rarewares or Fink Project?

https://www.steinberg.net/nc/en/support ... nts-7.html
(Maybe Rarewares has a newer version now).

The LAME page on sourceforge says the Fink Project has lame binaries for mac.

Have you tried the Fraunhofer mp3?

AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Re: Updating LAME codec

Post by AlexBarton » Thu Jan 24, 2019 10:58 am

yea Fraunhofer is my preferred, I got the different length issue with that codec also,
Its only because the Reaper mp3 convertion matched the length of the wav files perfectly that i started investigating the LAME encoding, and presumed an update would sort this issue, i managed to find an updated LAME codec that installed correctly late last night, which updated to 3.99.5 (which matches the reaper codec), but still have the same issue, regardless of if i rendered out at the same time as the wav's, or batch converted to mp3 separately.

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Thu Jan 24, 2019 12:00 pm

Do you have these settings activated? (WaveLab 9.5.40)
2019-01-24_12-00-00.png
(19.39 KiB) Not downloaded yet
Philippe

AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Re: Updating LAME codec

Post by AlexBarton » Thu Jan 24, 2019 1:15 pm

I didn't initially when i first had the fault PG, as soon as i saw those tickboxes i thought it would solve the issue
they are grey'ed out on the LAME encoder, and i can tick one or the other with the fraunhofer, (its a 192kb mono file being created)

i have just discovered, that if i put the mp3's i created in reaper, that they come up long in wavelab.
so ones i generate in WL are long in reaper, ones i generate in reaper are long in WL, is there anything i am missing?

FYI the client is using reaper to match the wavs & mp3's in the timeline as part of their QC process
Last edited by AlexBarton on Thu Jan 24, 2019 1:46 pm, edited 1 time in total.

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Thu Jan 24, 2019 1:24 pm

These options are only usable with the Fraunhofer encoder.
Philippe

AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Re: Updating LAME codec

Post by AlexBarton » Thu Jan 24, 2019 1:48 pm

thanks PG, made a mistake above, sorry,
i have just discovered, that if i put the mp3's i created in reaper, that they come up long in wavelab.
so ones i generate in WL (with the box ticked for time delay and compensation) are long in reaper, ones i generate in reaper are long in WL, is there anything i am missing?

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Thu Jan 24, 2019 4:24 pm

When you mean long, do you mean silence is added at the start or end? How much?
Philippe

AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Re: Updating LAME codec

Post by AlexBarton » Fri Jan 25, 2019 11:17 am

over the 26hr 13min length (114 files in total), the total mp3 audio is longer at the end by 7.48 seconds compared to the uncompressed wav's
as my files start and end with silence its hard to say for sure if its adding silence at the front or end of each file, the sync between the 2 does begin to slip / be noticeable after the 1st hour or so, in terms of hearing it, seeing the waveform slip slightly, and seeing the clip start in the montage be in a different place to the coinciding wav.

i'm now wondering if it is possibly that the mp3 encoding process adds milliseconds of silence to the front and rear of each file? and just something that occurs

S-EH
Member
Posts: 356
Joined: Sat Dec 18, 2010 12:47 pm
Contact:

Re: Updating LAME codec

Post by S-EH » Fri Jan 25, 2019 1:29 pm

RME Fireface 800, WaveLab, Cubase...

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Sat Jan 26, 2019 12:12 pm

AlexBarton wrote:
Thu Jan 24, 2019 1:15 pm
ones i generate in WL are long in reaper, ones i generate in reaper are long in WL, is there anything i am missing?
FYI the client is using reaper to match the wavs & mp3's in the timeline as part of their QC process
The same mp3 will appear different in nearly every program in my experience. Different amounts of silence will be added to the beginning (delay) and end (padding) when encoding and when decoding.

https://wiki.hydrogenaud.io/index.php?title=MP3

Even the gapless mp3s made in Wavelab will probably only be gapless in Wavelab, and will only match the exact length of the wav in Wavelab. When opened In other programs and players they will not necessarily match or be perfectly gapless, in my experience.

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Sat Jan 26, 2019 12:33 pm

Even the gapless mp3s made in Wavelab will probably only be gapless in Wavelab
No, this is not a WaveLab feature, but a Fraunhofer feature. Hence it's pretty universal.
Philippe

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Sat Jan 26, 2019 12:34 pm

over the 26hr 13min length (114 files in total), the total mp3 audio is longer at the end by 7.48 seconds compared to the uncompressed wav's
I guess each of the 114 files bring a gap. But how do you verify this sum of 7.48 sec?
Philippe

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Sun Jan 27, 2019 5:41 am

PG wrote:
Sat Jan 26, 2019 12:33 pm
Even the gapless mp3s made in Wavelab will probably only be gapless in Wavelab
No, this is not a WaveLab feature, but a Fraunhofer feature. Hence it's pretty universal.
But it's not gapless in any players I've tried (iTunes, Foobar, XLD, Media Monkey). It clicks just as badly as Wavelab Lame files with spliced 1khz tone. iTunes is the best of them for playback, getting about half clean, but the other half consistently clicking.

it's great how the gapless mp3 is trimmed and lines up perfectly with the wav file in Wavelab now, but I don't see anything like that when the gapless mp3 is opened in Pro Tools or Reaper (standard different amounts of delay and padding added to the beginning and end of the file in those programs, as expected I guess, so I'm not complaining about that).

But I don't see any benefit in any players with the Wavelab gapless.

Somehow Foobar and XLD (with LAME) and iTunes (Fraunhofer based?, I don't know) make MP3s with PERFECT transitions between the 3 programs and any other players I've tried. I don't know if Foobar and XLD add more useful information in the headers or how they do it but something is different between the way they do it and how Wavelab does it with LAME, and it's not just the LAME version. Those programs are also better and more universal with transitions than Sonnox Pro Codec too.

If I had a critical album that was all crossfades and I wanted it to be as seamless as possible in as many players as possible, I'd just convert the 32 bit float wav masters to 320k MP3 in iTunes.

AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Re: Updating LAME codec

Post by AlexBarton » Tue Jan 29, 2019 12:25 pm

over the 26hr 13min length (114 files in total), the total mp3 audio is longer at the end by 7.48 seconds compared to the uncompressed wav's
yea thats what i am lead to believe PG, looking at the previous posts about mpeg headers etc.

i've done a few more tests since (time / delay boxes ticked vs not), i compare the wav files & mp3 files (fraunhofer, with the boxes ticked) generated in WL (set to no gaps as i add these manually during an edit), the mp3's are 5.363 seconds longer in reaper, verified by adding markers in the timeline to measure the difference, however they DO match in wavelab perfectly.

rendering the mp3's in reaper (LAME) from the wav's created in wavelab gives me this
length of the wav's from WL and mp3's from Reaper is the same in reaper.
in WL in 2 seperate montages - Wav's 26hrs:13, MP3's 26:05:19

if i mp3 convert the WL files using switch (an external mp3 encoder) those and the wav's are match the same length in reaper.
i haven't imported those into WL yet to see that effect yet.
Last edited by AlexBarton on Tue Jan 29, 2019 12:29 pm, edited 1 time in total.

AlexBarton
New Member
Posts: 8
Joined: Wed Jan 23, 2019 8:23 pm
Contact:

Re: Updating LAME codec

Post by AlexBarton » Tue Jan 29, 2019 12:28 pm

bob99 wrote:
Sun Jan 27, 2019 5:41 am
Somehow Foobar and XLD (with LAME) and iTunes (Fraunhofer based?, I don't know) make MP3s with PERFECT transitions between the 3 programs and any other players I've tried. I don't know if Foobar and XLD add more useful information in the headers or how they do it but something is different between the way they do it and how Wavelab does it with LAME, and it's not just the LAME version. Those programs are also better and more universal with transitions than Sonnox Pro Codec too.

If I had a critical album that was all crossfades and I wanted it to be as seamless as possible in as many players as possible, I'd just convert the 32 bit float wav masters to 320k MP3 in iTunes.
thanks Bob this helps alot, i've also just downloaded switch which i've been told also does a good job, i haven't imported in the 26hrs into WL yet to see whats what, its what my client uses to convert their mp3's from their reaper wav exports (they are reaper setup)

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Wed Jan 30, 2019 10:25 am

bob99 wrote:
Sun Jan 27, 2019 5:41 am
Somehow Foobar and XLD (with LAME) and iTunes (Fraunhofer based?, I don't know) make MP3s with PERFECT transitions between the 3 programs and any other players I've tried. I don't know if Foobar and XLD add more useful information in the headers or how they do it but something is different between the way they do it and how Wavelab does it with LAME, and it's not just the LAME version. Those programs are also better and more universal with transitions than Sonnox Pro Codec too.
I don't know why I never noticed this before, but it appears that Wavelab is possibly the only program using LAME, that is not using a LAME header when making CBR and VBR. If this is the information the players are looking for in gapless, it would help explain why Foobar LAME, XLD LAME, xRecode LAME, MediaHuman LAME, etc. might perform seamlessly in many players while Wavelab LAME can't. Can the LAME or XING header be added, because that seems to be standard. It would probably make the Wavelab LAME MP3 files perform much better if not perfectly for gapless in many players.
mp3diags composite.png
(21.6 KiB) Not downloaded yet
Regarding Fraunhofer MP3 I haven't had luck with any of the Fraunhofer MP3 programs (Windows Media Player, Sonnox, Wavelab) making gapless MP3s, except iTunes, which apparently uses Fraunhofer, but saves relevant gapless info in the ID3. Still looking at how that works.

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Tue Feb 12, 2019 7:07 am

I've been trying LAME command-line just to see what commands are available, and found the -t switch, which suppresses the LAME header and gapless info tags (delay and padding etc.) Apparently Wavelab is using this switch, so there is no LAME header or gapless info in Wavelab LAME MP3.

I'd like to ask that this please be changed because it's making the Wavelab LAME MP3s the worst performing LAME for gapless out there. I haven't found one other program using LAME doing this, and it's not normal. (and I've checked out a lot of programs.) The default is to include the header and tags. When this is done making files with the command line program, with and without the -t flag, the gapless performance follows as expected.

LAME MP3 can be perfectly gapless with split sine waves in iTunes and Foobar and Media Monkey and probably a lot of other players if this information is not excluded, so I'd like to ask that the -t switch please not be used, because I'd like to keep using Wavelab with LAME.

The new FH gapless MP3 in Wavelab 9.5 is ok, but the only player I've found it to be gapless is in iTunes (I was wrong when I said it wasn't gapless in iTunes earlier. My test files were too short, less than 10 secs. When I increased them over 10 secs, the FH gapless was fine in iTunes). But the FH gapless does not test gapless in any other players I've tried.

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Tue Feb 12, 2019 7:54 pm

-
LAME MP3 info, encoded with -t switch (as in Wavelab):
-
LAME MP3 info with -t switch.PNG
(3.81 KiB) Not downloaded yet
-
-
LAME MP3 info, encoded without -t switch (as in all other programs I've found):
-
LAME MP3 info without -t switch.PNG
(6.87 KiB) Not downloaded yet
-
PG, please can this setting be changed to NOT include the -t switch in Wavelab's LAME encoding. It's how all other programs I've found do it (without the -t switch), and it has a direct effect on the gapless ability and gapless performance of the files in players. I guess the -t switch was probably originally used in Wavelab to include as little unnecessary info as possible, but including the LAME Header and gapless info (by NOT using the -t switch) has been the standard (and default) encoding used in all other programs I've found, for a number of years. And it makes the files gapless in many players, including iTunes.

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Wed Feb 13, 2019 7:01 pm

AlexBarton wrote:
Thu Jan 24, 2019 10:58 am
yea Fraunhofer is my preferred, I got the different length issue with that codec also,
Its only because the Reaper mp3 convertion matched the length of the wav files perfectly that i started investigating the LAME encoding, and presumed an update would sort this issue, i managed to find an updated LAME codec that installed correctly late last night, which updated to 3.99.5 (which matches the reaper codec), but still have the same issue, regardless of if i rendered out at the same time as the wav's, or batch converted to mp3 separately.
Judging from my testing using LAME command line, this discrepancy between Wavelab mp3 timings vs the orig. wav in Reaper (and probably any other DAWs using LAME) will be solved if the Wavelab LAME encoding is made to include the LAME header and gapless info, no -t switch, as it's done in other programs. Wavelab LAME mp3 times should then match the wav when opened in Reaper, as Reaper LAME MP3s do. And the Wavelab LAME will match the wav times when opened in Wavelab too, (unless it's being decoded by the Fraunhofer in Wavelab, and doesn't decode as expected).

All LAME made in other programs will decode correct length in Reaper as far as I know, because they have the LAME header and gapless info. If the LAME -t switch is removed in Wavelab, this would be fixed with Wavelab LAME too.

The Wavelab 9.5 Fraunhofer gapless MP3 doesn't decode correct length in Reaper or Pro Tools (not sure why it doesn't with Pro Tools because PT supposedly uses Fraunhofer, although I'm not using the most current PT). Silence delay and padding are added to the FH gapless in decode in those DAWs. The WL FH gapless does decode correct length in Cubase, probably because Cubase uses Fraunhofer. The only places I've found the WL FH gapless to be gapless/correct length is in Wavelab, Cubase, and iTunes.

LAME can be gapless in more players, and correct length in DAWs if this change is made in the way Wavelab makes LAME (don't use the -t switch). That's how every other program encodes LAME (no -t switch), and it really needs to be changed to be that way in Wavelab. It will solve the gapless problem, and it will solve the incorrect length problem in other DAWs.

Can this please be changed PG?

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Wed Feb 13, 2019 9:22 pm

WaveLab does not use a command line version of lame, there is no -t switch for instance that WaveLab is using. IOW, there is not necessarily an easy way to achieve you request. I might have a look, though.
Philippe

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Thu Feb 14, 2019 6:08 am

PG wrote:
Wed Feb 13, 2019 9:22 pm
WaveLab does not use a command line version of lame, there is no -t switch for instance that WaveLab is using. IOW, there is not necessarily an easy way to achieve you request. I might have a look, though.
Thank you PG, I'd really appreciate it. The LAME header is visible in MP3Diags. The delay, padding, accurate length info is visible in Foobar 2000. I did find one other program doing it the same as Wavelab today, Goldwave. But it's the only one I've found.

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Sat Feb 16, 2019 10:18 am

PG wrote:
Wed Feb 13, 2019 9:22 pm
WaveLab does not use a command line version of lame, there is no -t switch for instance that WaveLab is using. IOW, there is not necessarily an easy way to achieve you request. I might have a look, though.
PG, all of the programs I've looked at use a dll, like Wavelab, not the exe. Yet they all turn out files that look EXACTLY like my screenshots: LAME header and gapless/exact length info. So it must be a common thing to do with the dll. Mac, I don't know, but XLD on Mac does exactly the same thing.

And that correlates with the command line exe default behavior with no switches: You get exactly what you see in my screenshots.

PG
Moderator
Posts: 7009
Joined: Wed Dec 15, 2010 6:15 pm
Contact:

Re: Updating LAME codec

Post by PG » Sat Feb 16, 2019 9:53 pm

I experimented a bit with the xing header in lame, but unfortunately, it does not work properly when embedding certain metadata (eg. picture), in which case lame fails.
I must say this is not enough a priority for me to spend more time on this now.
Philippe

bob99
Senior Member
Posts: 2526
Joined: Fri Jan 07, 2011 2:49 am
Contact:

Re: Updating LAME codec

Post by bob99 » Sun Feb 17, 2019 7:26 am

PG wrote:
Sat Feb 16, 2019 9:53 pm
I experimented a bit with the xing header in lame, but unfortunately, it does not work properly when embedding certain metadata (eg. picture), in which case lame fails.
I must say this is not enough a priority for me to spend more time on this now.
Thanks for checking it out PG. When there's time I really think it should be fixed. It will fix the OP's LAME inaccurate time problem in other programs using LAME (but probably not in Wavelab if Fraunhofer is decoding in Wavelab).

I've tried using the latest LAME 3.1 lame_enc.dll on Rarewares in Wavelab but it makes no difference. It works, but Wavelab is still not adding the lame header/delay/pad/accurate. It really seems there's something in Wavelab (and Goldwave) dealing with the dll strangely, because you can copy the libmp3lame.dll from Reaper and Acoustica, put it in Wavelab, rename it to lame_enc.dll, and Wavelab will be ok with it. But in Wavelab it still doesn't add the LAME Header or delay/pad/accurate, while Reaper and Acoustica do add those using the exact same dll.

Like I said the Fraunhofer gapless is ok but it's extremely limited in it's usefulness if most players and DAWs are not going to decode it as gapless, which really seems like it might be the case.

It really seems like Wavelab should be able to create the LAME like nearly every other program, with the LAME Header, etc. That would cover a lot more players and DAWs.

Post Reply

Return to “WaveLab Pro 9 | WaveLab Elements 9”

Who is online

Users browsing this forum: No registered users and 1 guest