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)
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.
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
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?
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
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.
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.
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.
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.
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)
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.
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.
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.
LAME MP3 info, encoded with -t switch (as in Wavelab):
LAME MP3 info, encoded without -t switch (as in all other programs I’ve found):
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.
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.
