hi
i set up a audio montage w cd track id-s, isr codes and everything, and rendered the montage from 44.1 kHz 24 to
mp3 (vbr, best quality)
the resulting track times of the mp3s varied significantly from the original cd tracks, not all by the same amount, resulting in mp3s which where up to 20 seconds longer than the original tracks?
i´ll try to reproduce this, has anyone else experienced anything similar?
thx
k
Where do you check this length? For instance, some application like Windows Media Player and iTunes, report a slightly wrong length, while VLC is good. Actually, this finding is about very long songs with CBR.
With VBR, since no header is written in the file, the length finding is less accurate because of the “variable” bit rate precisely.
When you reopen the song, is all data present?
hi pg
i checked the length in quicktime.
it plays back normally.
i´ll have a look at it later today, what happens if i import it, will report…
k
Hi Phillipe,
so i tested this again, and i can repeat the error.
With the same Audio Montage, rendered the files as Mp3 FH vbr hq.
Original files are 44.1kHz 24bit, Audio Montage, MBit Dither to 16bit in the Dithering slot, and thats it.
The first Track of the Montage shows a different duration in
Quicktime 6:46 instead of 6:20 (QT even plays back the extra duration as silence)
Finder (Get Info) 7:48 instead of 6:20
iTunes gets it right and shows the right duration.
Mp3 Import into WL results in a correct file.
And i tried it with a new Master, same Situation, this time all Mp3s have a different duration in Quicktime and Finder, in Finder are some same, some different then Quicktime, but also all off. All durations are between 6sec and over 1 minute off.
I´m on OSX 10.8.5 WL 8.5.2.
Thanks
Kap
anyone?
You mention issues found in third-party players, not in WaveLab, right?
Ok i´ll email Apple.
…
The issue does not happen with other mp3 converters like XLD which i use.
And this experience teaches me to stick to them.
And to check if every feature WL has actually does what it should do and what one would expect.
So rendering to mp3 is apparently off the list of “features one can use within WL”
I mean, it´s 2015 and this program cost me 500€.
For Wavelab 9 i would wish less features + less bugs, and increased stability and compatibility. Thats all i need.
Excuse me, but once in a while things have to be said.
I’m in agreement with this. I’ve encountered so many bizarre bugs with Wavelab that I can’t help but wonder if there have been problems I didn’t catch at some point, I’m sure there have been.
I’m all about double checking files, but it seems that Wavelab is capable of inducing problems you’d never even think you’d have to check for.
This is a big part of why I made a feature request for an audio null test track. Just a simple audio track in Wavelab montage that can bypass all plugin paths (montage master and global master section) so you can load your rendered files back into the montage, invert the phase and test for plugins that didn’t render and other oddities.
I’m about to render off some various file types for a project this afternoon. I’ll see what I find regarding the mp3 times when loaded into various playback apps.
VBR pose a special problem to decoders. The problem is as follows: if for example we want to jump 30 seconds forward, how many bytes in the file does this correspond to? Or what is the duration of the file? Having constant rate files, this is easy to calculate by simply dividing the time by the constant frame length. For VBR this does not work. The frame length varies highly.
A solution is to prepend the file with a header, a pseudo mp3 frame, that decodes into silence and that carries information (an index table) about entry points in the file.
Decoders that are aware of this frame can extract this information.
But this is not an official standard. This is why that has never been a priority to add this feature.
But this could come, as an option.
Is that what XLD is doing to get it to display correctly? Can an MP3 really display over 1 minute off just because of VBR ?? Don’t know kapverden’s total song length on that one but that seems extreme. Unless it’s extreme unusual program material.
Also how could iTunes get it right if the file did not contain this pseudo mp3 frame header? But quicktime and finder get it wrong?
Does this only happen with Wavelab VBR MP3? Does it not happen with Wavelab VBR AAC?
Also how could iTunes get it right if the file did not contain this pseudo mp3 frame header? But quicktime and finder get it wrong?
Maybe iTunes decodes a couple of frames to make a better guess about the average bit rate, while the others maybe only rely on the 1st frame of the file.
Thanks PG.
LAME says they support the VBR header, calling it a de facto standard. (unclear about always used or not).
http://wiki.hydrogenaud.io/index.php?title=LAME#VBR_header_and_LAME_tag
Possibly LAME is what XLD is using? And I would assume Wavelab LAME would use it, and not have this issue?
Seems odd the Fraunhofer wouldn’t.
There are actually 2 “standards” for this.
That makes it more difficult. Sorry PG, I don’t want to belabor this, because it’s probably been like this since Wavelab 4 with possibly no complaints, and most people would probably read the timing in iTunes (which is fine with Wavelab Fraunhofer MP3, LAME MP3, and Fraunhofer AAC for timings, I’ve found). But since this is found, it seems it should be addressed, since other programs apparently have. FWIW, I found Wavelab FH MP3 and LAME MP3 are very wrong in Mac Finder and Windows Explorer. However Wavelab AAC is fine in Mac Finder. (Win Explorer not applicable for AAC).
The specific tracks i experienced this with were around 6:20 minutes.
As described before f.e. Quicktime not only show a wrong length of 6:48 or 7:20, but - and thats it - also tried to play it back!!
I wouldn´t care that much if only the display was wrong.
iTunes managed to get it right though.
XLD does indeed use the LAME encoder.
The fact that there are various standards … we need to be pragmatic:
My wish is that it does what it should do, and LAME seems to do it right and FH seems not to.
It is kinda embarrassing to explain to customers that your mastering software f***s up MP3s.
They obviously end up being alienated… What else might be wrong?
No bad experience with encoding AAC through WL here.
Only with MP3 VBR.
So are you saying LAME in WL also is correct?
Don’t think so Arjan. Actually they’re further off in Mac Finder, Mac Quicktime, and Windows Explorer than the Fraunhofers.
If VBR headers are optional in LAME and Fraunhofer as they appear to be, they appear not to be used in Wavelab. I guess that’s worked fine all these years (including Wavelab 4) (the Wavelab VBR files work fine in iTunes and VLC, etc.), and why add something technical if nobody complains. The Wavelab VBR files even work fine in Windows Quicktime. It’s only in Mac Quicktime (and a couple others) they’re misreported and mis-timelined. But it really appears the VBR headers should be added because the Wavelab VBR’s are misreported and mis-timelined in the following:
Mac Finder (by a lot)
Windows Explorer (by a lot)
Foobar (by a lot)
JRiver (by a little)
Apparently many other programs that make VBR MP3s use VBR headers and so don’t have this issue.
Foobar player shows the same thing kapverden was describing for the Mac Quicktime player. A 5 minute song will read as 10 (!) minutes, and the playbar will indicate 10 minutes and can be scrolled anywhere in that 10 minutes. But in Foobar the file will play and then stop after the allotted 5 minutes, not continue playing the timeline like Mac Quicktime does.
It’s not right. The files should at least be made to display correct in the Mac and Win OS’s, and that fix will probably fix the players.