Itunes lame encoder7/30/2023 ![]() When this is done making files with the command line program, with and without the -t flag, the gapless performance follows as expected. (and I’ve checked out a lot of programs.) The default is to include the header and tags. I haven’t found one other program using LAME doing this, and it’s not normal. 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’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. It would probably make the Wavelab LAME MP3 files perform much better if not perfectly for gapless in many players. Can the LAME or XING header be added, because that seems to be standard. might perform seamlessly in many players while Wavelab LAME can’t. 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. ![]() 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. I haven’t imported those into WL yet to see that effect yet. 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. In WL in 2 seperate montages - Wav’s 26hrs:13, MP3’s 26:05:19 ![]() Length of the wav’s from WL and mp3’s from Reaper is the same in reaper. Rendering the mp3’s in reaper (LAME) from the wav’s created in wavelab gives me this 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. ![]() Yea thats what i am lead to believe PG, looking at the previous posts about mpeg headers etc. 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 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. Those programs are also better and more universal with transitions than Sonnox Pro Codec too. 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. 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. 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).īut I don’t see any benefit in any players with the Wavelab gapless. ![]() iTunes is the best of them for playback, getting about half clean, but the other half consistently clicking. It clicks just as badly as Wavelab Lame files with spliced 1khz tone. Hence it’s pretty universal.īut it’s not gapless in any players I’ve tried (iTunes, Foobar, XLD, Media Monkey). No, this is not a WaveLab feature, but a Fraunhofer feature. Even the gapless mp3s made in Wavelab will probably only be gapless in Wavelab ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |