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?
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.
Can this please be changed PG?
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.
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.
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.
Do you know another application that can embed a picture at the front of the mp3 file (where iTunes needs to find them), while still having the lame header? (the right name being the ‘xing’ header).
This is where I failed when I tried.
Foobar 2000.
I think there are probably more.
PG, the weird thing about this is that all of the programs add EXACTLY the same 4 items (plus the header), as if it’s just one command that gets you there. In the LAME command line program it is one command, the -t switch, which suppresses the header and 3 of the 4 info lines (delay, padding, and accurate length). Without any switches, all of those, including the header, are there by default.
However I found out today that Foobar uses the LAME exe. But I’ll look at the programs using a dll and see what the situation is.
Acoustica 7 can do it, and they use a LAME dll. Acoustica and Reaper use exactly the same dll, libmp3lame.dll v3.99.2.5. I don’t know where they got it but their dll’s are identical. And the dll works in Wavelab if renamed, but like I said the header is not added in Wavelab. I’ll post screenshots later.
I guess this is the problem. The header (and tail) need to be added by WaveLab because of the enhanced meta-data support of WaveLab. Therefore, this can’t work out of the box and some special processing would need to be implemented.
Thanks PG. I appreciate that Wavelab has to cover a lot of metadata cases on Windows and Mac with various filetypes, but I really hope this can be implemented, because I had a run-in with accurate length myself a few days ago. All of the programs using LAME that are capable of adding cover art use an xing header and LAME INFO tag and have this solved for iTunes. Amazon is still using LAME and I don’t foresee that changing, and they make more MP3 files than anybody. Ideally Wavelab would decode LAME files with LAME, because LAME and Fraunhofer really don’t appear to be very compatible when it comes to accurate length and gapless decoding each other. If that was done, Wavelab would be back and forth accurate length compatible with other DAWs like Reaper that use LAME. iTunes seems to be one of the only programs that can handle decoding both, but it has it’s own special routines for dealing with gapless and accurate length.
Ideally Wavelab would decode LAME
Lame does not included a decoder. But it is sometimes associated with one called mpg123.
Don’t forget that Fraunhofer created the mp3 format. On another hand, lame is not a well maintained project. For example, last version I tried 3.1 did not build successfully on Mac.
Putting some effort to support some non-official version which is not well maintained either, is difficult.
Now, I know this Lame version is popular, because of historical reasons (availability), therefore I don’t discard your POV.