Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: vbr files displaying time inaccurately (Read 11947 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

vbr files displaying time inaccurately

Hi guys.  I searched the forum, but the last post I found addressing this topic was about 4-5 years old, and didn't seem to provide the solution I'm looking for.

It seems that all my VBR files don't display the track remain / total track time correctly.  For example, a song I know to be 4:30 might display as 33:15 or so.  Is there something I should do to fix this?

Lame tags I've been using are -q, -b, --resample, and sometimes --lowpass, also either -m s or -m m.
I haven't used vbr in the past 2-3 years or so because of this time display issue.  I'm currently running Lame 3.97 b3 or b4.  Would 3.98 b6 have this fixed, or has it already been fixed - I'm just doing something wrong?

Also, it doesn't matter what player I play it on.  Winamp 5.5, my old Sony D-NS921F CD player (which was built like a tank, but unfortunately stolen), etc.  They all display it wrong.

If I encoded the tracks wrong, is there a way to retroactively put the proper times (tags?) in them, without having to re-encode the entire songs?

And for songs I haven't yet encoded, what tags should I be using?  I'd like to use VBR again, but I also like my track times to be displayed accurately.

Also, I'm looking for a replacement CD/DVD/HDD MP3 player that's built like a tank and skip free, with a good UI, to replace a badly skipping (among other things) Sony D-NE330 mp3 cd player.  I have a topic started in Audio Hardware (edit - mistakenly said general audio), though, so I won't go into that in this topic.

vbr files displaying time inaccurately

Reply #1 –
what ripper do you use?  in my experience, when directly ripping and encoding using the lame.exe file (not the dll), lots of strange things happen to the resulting file, one of which is incorrect time display.

you could try ripping to wave then encoding the file separately (whether your ripper is EAC or even good ol' Audiograbber).

for the earlier encodes, you could try vbrfix (i'm not sure, but i hope this works) to fix length/time display.

i'm not sure if there was lame 3.97b3 or b4 though.

EDIT: vbrfix will repair your mp3 tag losslessly, with no harm to the original file.
"Listen to me...
Never take unsolicited advice..."

vbr files displaying time inaccurately

Reply #2 –
Quote from: Rio on
what ripper do you use?  in my experience, when directly ripping and encoding using the lame.exe file (not the dll), lots of strange things happen to the resulting file, one of which is incorrect time display.

you could try ripping to wave then encoding the file separately (whether your ripper is EAC or even good ol' Audiograbber).

for the earlier encodes, you could try vbrfix (i'm not sure, but i hope this works) to fix length/time display.

i'm not sure if there was lame 3.97b3 or b4 though.

EDIT: vbrfix will repair your mp3 tag losslessly, with no harm to the original file.


I use CD-DA Xtractor to rip, then Razorlame to encode, but not all in one operation - I have to initiate RL separately after Xtractor has finished doing its thing.

I've been using my parents' computer, so haven't had admin access.  I now have my own (as of yesterday, although I'm still setting it up) so I can pretty much install anything I want.  (before, I haven't really been able to try things like EAC, Audiograbber, etc.  CD-DA Xtractor & Lame would work fine without installing as root/admin/etc, though)

I couldn't remember which version, but I'm sure somewhere in there it was a beta of 3.97 or so.

I'll have to give that vbrfix a shot.  btw, for future reference, what mp3 tag do I need to pay attention to when I encode future files?

vbr files displaying time inaccurately

Reply #3 –
since i have no experience with razorlame, i downloaded the latest razorlame version (1.1.5.1342) and used lame 3.97 (i guess what you have there at your cpu is 3.97b2).

anyway, i tried to encode one wave file, ticking the "disable writing of the vbr tag" box in the "lame options > vbr" menu.  this gave me a resulting file with inaccurate time, just like yours.

you have to un-tick this option to get an accurate time display of your future vbr mp3 files.
"Listen to me...
Never take unsolicited advice..."

vbr files displaying time inaccurately

Reply #4 –
Quote from: Rio on
since i have no experience with razorlame, i downloaded the latest razorlame version (1.1.5.1342) and used lame 3.97 (i guess what you have there at your cpu is 3.97b2).

anyway, i tried to encode one wave file, ticking the "disable writing of the vbr tag" box in the "lame options > vbr" menu.  this gave me a resulting file with inaccurate time, just like yours.

you have to un-tick this option to get an accurate time display of your future vbr mp3 files.


Hmm.. maybe that's what's going on... I thought that did the opposite hehe  or something - i don't remember specifically what...

What program do you like to use?  I like the lame + razorlame combo cause it gives me a lot of control over advanced settings, but if there's something better, I might want to look into it.

(Also, what are some good WMA, OGG, FLAC, AAC, MPEG4, XviD, H.264, etc. encoders that give me as much control as or more than LAME?)

vbr files displaying time inaccurately

Reply #5 –
i still use ol' audiograbber + lame
"Listen to me...
Never take unsolicited advice..."

vbr files displaying time inaccurately

Reply #6 –
I dl'd and tried vbr fix and it didn't work for me.  I'm wondering what I could have done wrong...  any ideas?

Also, I went to try to decode some of my mp3s back to wav, then was going to try to re-encode the VBR, but somehow I did something wrong, it came up with errors, and, well... basically several of my mp3 files in one folder somehow now all took up 5k (and had nothing in them).  I also made the mistake of deleting the WAVs.  GRRR...  so now I'll have to dig out the original CD-R that has the songs on it (which I haven't touched in a few years or more)

vbr files displaying time inaccurately

Reply #7 –
Quote from: pianoplayer88key on
I dl'd and tried vbr fix and it didn't work for me.  I'm wondering what I could have done wrong...  any ideas?


A few years ago, I had the same problem using LAME, but adding CRC values to my VBR files fixed it for good ...

Quote
-p    error protection

    Turn on CRC error protection.
    It will add a cyclic redundancy check (CRC) code in each frame, allowing to detect transmission errors that could occur on the MP3 stream. However, it takes 16 bits per frame that would otherwise be used for encoding, and then will slightly reduce the sound quality.


Just add "-p" and you should be fine.

Cheers,
Maggi

vbr files displaying time inaccurately

Reply #8 –
I was under the impression that all mp3 players ignore the crc.

vbr files displaying time inaccurately

Reply #9 –
dunno ... at least winamp had problems displaying the accurate total playtime until I added CRC values

vbr files displaying time inaccurately

Reply #10 –
Quote from: Maggi on
Quote from: pianoplayer88key on

I dl'd and tried vbr fix and it didn't work for me.  I'm wondering what I could have done wrong...  any ideas?


A few years ago, I had the same problem using LAME, but adding CRC values to my VBR files fixed it for good ...

Quote
-p    error protection

    Turn on CRC error protection.
    It will add a cyclic redundancy check (CRC) code in each frame, allowing to detect transmission errors that could occur on the MP3 stream. However, it takes 16 bits per frame that would otherwise be used for encoding, and then will slightly reduce the sound quality.


Just add "-p" and you should be fine.

Cheers,
Maggi


How would I do that with songs that are already encoded?  Should I decompress them and recompress them with options -V 0 -b 8 -B 320 --resample 44.1 --lowpass 22.05 -m s -p -k, and what other options (and I suspect there's a few redundant ones in there as well)?

vbr files displaying time inaccurately

Reply #11 –
If your files don't have a proper VBR frame, you can add it using Foobar2000 (Fix MP3 Header). It's that simple. You absolutely don't need to encode again.

I've seen some crazy MP3 files which had reserved space at the beginning for tags or whatnot and the VBR frame wasn't there. Most likely the program adding CRCs also computed and wrote VBR data.

Quote
Also, it doesn't matter what player I play it on. Winamp 5.5, my old Sony D-NS921F CD player (which was built like a tank, but unfortunately stolen), etc. They all display it wrong.

Only programs supporting the Xing VBR standard frame will be able to display time correctly. Winamp could do that for ages, but not all players are the same.

Quote
(Also, what are some good WMA, OGG, FLAC, AAC, MPEG4, XviD, H.264, etc. encoders that give me as much control as or more than LAME?)

From the list above only WMA does not have a nice, small tweakable encoder. Most websites I've come across tell to install big SDKs, distributives, or the Media Player.

vbr files displaying time inaccurately

Reply #12 –
Quote from: j7n on
I've seen some crazy MP3 files which had reserved space at the beginning for tags or whatnot and the VBR frame wasn't there. Most likely the program adding CRCs also computed and wrote VBR data.

Maggi seems to be saying that he encodes with lame, but depending on whether or not he uses the -P switch, vbr times either work or don't.

vbr files displaying time inaccurately

Reply #13 –
Quote from: pianoplayer88key on
How would I do that with songs that are already encoded?  Should I decompress them and recompress them with options -V 0 -b 8 -B 320 --resample 44.1 --lowpass 22.05 -m s -p -k, and what other options (and I suspect there's a few redundant ones in there as well)?


presuming you are using LAME for encoding, your flags are pretty messed up ... 

"-k" disables filtering, but you add a lowpass filter

"-b 8" is not possible with stereo files, "-b 32" would be minimum setting, but it is used automatically in VBR mode when possible

"-m s" will result either in larger files or degraded sound, depending on your footage, just use joint stereo instead


simply use "-V0 -q0 -p" if your aiming at the highest possible quality VBR mode with CRC protection, but the general consensus in these boards are that -V2 is indistinguishable from -V0 (maybe except for a few rare critical samples)


recompression will usually result in degraded sound quality anyways, so you should either re-rip everything properly or use the suggested methods of adding CRC values to your existing files


Quote from: pdq on
Quote from: j7n on

I've seen some crazy MP3 files which had reserved space at the beginning for tags or whatnot and the VBR frame wasn't there. Most likely the program adding CRCs also computed and wrote VBR data.

Maggi seems to be saying that he encodes with lame, but depending on whether or not he uses the -P switch, vbr times either work or don't.


Spot on ...

The only other workaround would be to let the decoder scan the entire file before it actually starts playing it.

Cheers,
Maggi

vbr files displaying time inaccurately

Reply #14 –
[quote name='j7n' date='Mar 4 2008, 06:20' post='550921']
If your files don't have a proper VBR frame, you can add it using Foobar2000 (Fix MP3 Header). It's that simple. You absolutely don't need to encode again.
[/quote]
I'll have to give it a shot.

[quote name='j7n' date='Mar 4 2008, 06:20' post='550921']
I've seen some crazy MP3 files which had reserved space at the beginning for tags or whatnot and the VBR frame wasn't there. Most likely the program adding CRCs also computed and wrote VBR data.

Quote
Also, it doesn't matter what player I play it on. Winamp 5.5, my old Sony D-NS921F CD player (which was built like a tank, but unfortunately stolen), etc. They all display it wrong.

Only programs supporting the Xing VBR standard frame will be able to display time correctly. Winamp could do that for ages, but not all players are the same.[/quote]
So.. does this mean that no matter what I do to try to do my VBR songs correctly, there'll be something out there made within the last 6 to 8 years that may not display the times correctly?

[quote name='j7n' date='Mar 4 2008, 06:20' post='550921']
Quote
(Also, what are some good WMA, OGG, FLAC, AAC, MPEG4, XviD, H.264, etc. encoders that give me as much control as or more than LAME?)

From the list above only WMA does not have a nice, small tweakable encoder. Most websites I've come across tell to install big SDKs, distributives, or the Media Player.
[/quote]
Where would I go to find the encoders you speak of?  I'd especially like some that are at least as tweakable, if not more so, than LAME, with GUIs.  (Also, I'm not limiting myself to those codecs - I used that list as an example.)

[quote name='pdq' date='Mar 4 2008, 06:25' post='550924']
[quote name='j7n' post='550921' date='Mar 4 2008, 10:20']
I've seen some crazy MP3 files which had reserved space at the beginning for tags or whatnot and the VBR frame wasn't there. Most likely the program adding CRCs also computed and wrote VBR data.
[/quote]
Maggi seems to be saying that he encodes with lame, but depending on whether or not he uses the -P switch, vbr times either work or don't.
[/quote]


[quote name='Maggi' date='Mar 4 2008, 06:54' post='550934']
[quote name='pianoplayer88key' post='550914' date='Mar 4 2008, 15:47']
How would I do that with songs that are already encoded?  Should I decompress them and recompress them with options -V 0 -b 8 -B 320 --resample 44.1 --lowpass 22.05 -m s -p -k, and what other options (and I suspect there's a few redundant ones in there as well)?
[/quote]

presuming you are using LAME for encoding, your flags are pretty messed up ... 

"-k" disables filtering, but you add a lowpass filter
[/quote]
ok... so should I use -k or --lowpass (sample frequency / 2)?  Or does VBR kind of have like a dynamic lowpass filter?

[quote name='Maggi' date='Mar 4 2008, 06:54' post='550934']
"-b 8" is not possible with stereo files, "-b 32" would be minimum setting, but it is used automatically in VBR mode when possible
[quote name='Maggi' date='Mar 4 2008, 06:54' post='550934']
Ok... just so long as the max range is available.  I just don't want it wasting bits when encoding silence, but I want it to have enough when encoding a complex symphonic orchestra cresendo.

[quote name='Maggi' date='Mar 4 2008, 06:54' post='550934']
"-m s" will result either in larger files or degraded sound, depending on your footage, just use joint stereo instead
[/quote]
What's the difference between stereo and joint stereo?  I want my stereo field aspect of the compression to be at least transparent, if not lossless.

[quote name='Maggi' date='Mar 4 2008, 06:54' post='550934']
simply use "-V0 -q0 -p" if your aiming at the highest possible quality VBR mode with CRC protection, but the general consensus in these boards are that -V2 is indistinguishable from -V0 (maybe except for a few rare critical samples)
[/quote]
I've been using -q 2 lately for my CBR files and have gotten fairly good results, except that in general (unless I'm trying to save space by encoding at 16kbps) I get noticeably better results by upping the bitrate a couple steps over what Lame recommends for the lowpass filter it uses (for example, if it lowpasses at 13kHz at 80kbps, I'll encode at 112kbps and force lowpass at 13khz).

[quote name='Maggi' date='Mar 4 2008, 06:54' post='550934']
recompression will usually result in degraded sound quality anyways, so you should either re-rip everything properly or use the suggested methods of adding CRC values to your existing files
[/quote]
There's quite a few (maybe several hundred thousand or more, for example) songs that I'll eventually need to re-rip (most for the first time, probably) and record off cassettes, LPs, etc.  Also I'll want a good way to do id3 tags.  For now I've been "tagging" them in the filenames (which I'd continue to do that, too).

vbr files displaying time inaccurately

Reply #15 –
here's a nice overview about LAME's VBR modes

http://www.hydrogenaudio.org/forums/index....showtopic=18091



and here's an excerpt from LAME's fine manual:

Quote
-m s/j/f/d/m    stereo mode

    Joint-stereo is the default mode for input files featuring two channels..

    stereo
    In this mode, the encoder makes no use of potentially existing correlations between the two input channels. It can, however, negotiate the bit demand between both channel, i.e. give one channel more bits if the other contains silence or needs less bits because of a lower complexity.

    joint stereo
    In this mode, the encoder will make use of correlation between both channels. The signal will be matrixed into a sum ("mid"), computed by L+R, and difference ("side") signal, computed by L-R, and more bits are allocated to the mid channel.
    This will effectively increase the bandwidth if the signal does not have too much stereo separation, thus giving a significant gain in encoding quality. In joint stereo, the encoder can select between Left/Right and Mid/Side representation on a frame basis.

    Using mid/side stereo inappropriately can result in audible compression artifacts. To much switching between mid/side and regular stereo can also sound bad. To determine when to switch to mid/side stereo, LAME uses a much more sophisticated algorithm than that described in the ISO documentation, and thus is safe to use in joint stereo mode.

    forced joint stereo
    This mode will force MS joint stereo on all frames. It's slightly faster than joint stereo, but it should be used only if you are sure that every frame of the input file has very little stereo separation.

    dual channels
    In this mode, the 2 channels will be totally independently encoded. Each channel will have exactly half of the bitrate. This mode is designed for applications like dual languages encoding (ex: English in one channel and French in the other). Using this encoding mode for regular stereo files will result in a lower quality encoding.

    mono
    The input will be encoded as a mono signal. If it was a stereo signal, it will be downsampled to mono. The downmix is calculated as the sum of the left and right channel, attenuated by 6 dB.


to sum it up, by default LAME will choose automatically whether it uses joint stereo or L/R stereo on a frame by frame basis, usually resulting in smaller files with higher quality

Maggi

vbr files displaying time inaccurately

Reply #16 –
Please fix your QUOTE BBcodes, or don't use them at all when referring to last couple posts above.

I don't know how 'hardware' players handle Xing frame in general. Any serious audio software for PC probably knows VBR at least 8 years. WinXP built-in DirectShow doesn't, but it's not a serious program.

Quote
(Also, what are some good WMA, OGG, FLAC, AAC, MPEG4, XviD, H.264, etc. encoders that give me as much control as or more than LAME?)
..
Where would I go to find the encoders you speak of?  I'd especially like some that are at least as tweakable, if not more so, than LAME, with GUIs.  (Also, I'm not limiting myself to those codecs - I used that list as an example.)

As with LAME, GUI frontends are often separate programs. I'm only using generic front-ends myself, so don't know about those.
OGG Vorbis - OggEnc2
FLAC - FLAC itself
AAC - Nero AAC Encoder
MPEG-4 ASP - Xvid
MPEG-4 AVC (H.264) - x264

Quote
Ok... just so long as the max range is available.  I just don't want it wasting bits when encoding silence, but I want it to have enough when encoding a complex symphonic orchestra cresendo.

Silence is encoded with the smallest possible frame size (32 kBit/s for 32, 44, 48 kHz) even if a min bitrate is set.

Quote
Also I'll want a good way to do id3 tags.  For now I've been "tagging" them in the filenames

I would add all metadata in tags and then format filenames based on this data. Filenames might get truncated or lost during copying.

vbr files displaying time inaccurately

Reply #17 –
-

vbr files displaying time inaccurately

Reply #18 –
Quote from: pianoplayer88key on
It seems that all my VBR files don't display the track remain / total track time correctly.  For example, a song I know to be 4:30 might display as 33:15 or so.  Is there something I should do to fix this?


Try to use mp3val in repair mode, please. If your problems haven't gone with your hardware player afterwards then we need to find another solution. Winamp is not a measure as Winamp does not show the times correctly in general for vbr MP3.

vbr files displaying time inaccurately

Reply #19 –
It doesn't? It did since the time Xing encoder was around.

vbr files displaying time inaccurately

Reply #20 –
It doesn't ! I see it daily with Winamp. fb2k is really accurate but not Winamp. Winamp uses both the size information in the mp3 header as well as a fast seeking algorithm optimized for speed (as far as I know) while foobar checks the real playing time.

vbr files displaying time inaccurately

Reply #21 –
Ah, you're talking about seeking.

vbr files displaying time inaccurately

Reply #22 –
Ok, so, at least for most of the VBR files I'm playing now, the incorrect time display is fixed.

However, quite often, the seek is wildly skewed.  I'll have, for example, played 2:30 into a song, then I'll briefly tap the forward to go forward, oh, say 10 seconds, but while the time display will "look right" the actual audio I'm hearing is from something like 0:20 into the song, for example.  What can I do to fix this?
(I'm thinking part of the seek problem is based on what the bitrate of the first frame is - often 8kbps or 16kbps or something like that due to very simple audio / silence at the very start of each track.  For example let's say the ABR is 128kbps, first frame is 8kbps.  You seek to a certain time into the song, but end up only being actually 1/16th of the way to where you thought you were supposed to end up.  Beyond that I don't know how to explain much.)

These VBR issues I've been having are enough to make me want to strictly encode in CBR.  I know VBR offers better quality for the file size than CBR, though, cause it's more efficient (using more bits when it needs to, and fewer bits when it's ok).

Main thing is I want to use a good compressed audio format that is compatible with pretty much ALL software/hardware made.  (That's one main reason I primarily use CBR mp3 cause there is hardly anything (with the exception of a few older Sony players that I'm aware of) that doesn't play it.

Will I need to reconvert all the VBR MP3s I have, or is there something I can do to change a tag in them, like the mp3val program referenced earlier in this thread?

Or, to ensure proper playback, time display, seeking, and compatibility with all hardware/software in existence, should I go back to exclusively using CBR mp3 for lossy audio and WAVE for lossless audio?
 

vbr files displaying time inaccurately

Reply #23 –
If you can upload one of these MP3's somewhere, I can check it out.  I didn't read the thread thoroughly, but my guess is a bad VBR tag.  Winamp handles properly written VBR (Xing) tags rather well.
If Winamp thinks the VBR header is invalid (bad file size field, etc), it resorts to guessing length based on the first few frames' bitrates and the file size.  Since the first few frames of many LAME encoded MP3's are 32kbps, the time tends to get greatly exaggerated when this happens.