I have Windows XP prof. I use the following programs for audio encoding:
- Audiograbber 1.81 with Lame 3.92 (.dll)
- Cool Edit Pro 2.0 (buit in mp3/mp3pro encoder)
- HeadAC3he with lame_enc.dll (for DVD ripping)

The problem comes when I try to playback the files:
Windows Media Player (ver. 8.0) CAN'T playback properly VBR/ABR MP3s (it messes up the duration showing them shorter than they are).
Winamp (ver. 3.0) on the other hand, playbacks VBR/ABR MP3s, but not the ones created with CoolEdit Pro.When it comes to these, it messes up the duration (it shows the track shorter than it really is).
BUT, another playback/DJ program I have (BPM Studio Professional ver. 4.2) plays ALL the VBR/ABR MP3 files without any problem, including the ones created with CoolEdit Pro.
So, what's the problem? Since BPM Studio playbacks properly the files created with CoolEdit Pro, there is nothing wrong with them. If anyone knows what's wrong, please post a reply.

There is no info in the mp3 file how long it is. So the most programs calculate the length of the audio with the filesize and the bitrate of the first frame, what´s ok for CBR, but not for ABR/VBR. So Xing (yes, the same xing creating this ****-mp3-encoder, they even did something good) invented the xing-vbr-header which is written by xing-encoders and lame for example automatically in vbr-files. from this header the decoder can read the average bitrate, the duration, etc. WinAmp read this header, but WMP not (M$ doesn´t support mp3). Your other program will most likely sacn the entire mp3 to get the length also in the file without a xing-header created with CEP2.
But you can create xing-headers manually: http://www.willwap.btinternet.co.uk/progra...rams/vbrfix.htm
For WMP, you can´t do anything, just don´t use it.

Windows media player has problems with VBR mp3 files, and MS doesn't care. That's pretty much the whoile story
Better use another program to play mp3s.

I've the same problem.
Winamp don't report correctly the duration and the bitrate.

The solution is VBR Fix (http://www.willwap.co.uk/): it will 'repair' the mp3 so winamp will report correctly both bitrate and file lenght.
The only problem is that then Encspot and Ear plug-in will report the file as encoded with Xing.

what is this ear plug-in?

No, Encspots reports the file has an Xing Header (which is true), but not that it is encoded with xing. At least not in the newest (probably last) version.

Ok, just play your ABR/VBRwith RealOne player and the player will automaticaly add a Xing header on your VBR MP3s!

The ear plug-in is a winamp plug-in you can found at www.helium2.com.
It is very useful and shows all info from tag, and the encoder used too.
About the encoder detection is not very reliable.

I notice that cue points aren't located accurately when using a single VBR mp3 file and cuesheet, in Winamp 2.81 with the mp3cue0.94 plugin. Normally I compress with Monkey's Audio, so I never noticed the issue before.

I tried to use the VBR Fix mentioned above but it just crashed (Win XP Pro).

Is there any other tool available to allow accurate track seeking using VBR MP3/cuesheet?

Thanks.

edit: I sent this info to the email on the "about " page of the plugin, but it bounced back, and http://www.guerillasoft.com/mp3cue has been down for a while.

You might want to try MP3/Tag Studio 3.01. It's ad-ware and makes my NT display flicker on start up and at other times, but it's very powerful and the file tools (button on right) allows you to access the Repair mp3 menu, which lets you repair/add VBR headers which may help the cueing to get it right or at least closer than previously.

Personally, I've given up on MP3cue and use the mp3splice output plugin for WinAMP 2.xx to give seamless playback (and it seem to be the only plugin that does this properly). It doesn't allow easy burning or seamless playback on portables (yet), but that's not an issue for me.

Dick Darlington

Winamp can read XING VBR header generated by LAME, but can't read VBRI VBR header that is generated by FhG Fastenc when encoding VBR files. Most other players also cannot read VBRI but can read XING header, so this is a fault of FhG for not releasing the specs of their header so that other players can add compatability.

I did an experiment; the first time I used LAME 3.92.exe and the when I jumped the the last track in the cue, it was early by about 20 seconds.

I re-ripped (EAC) and encoded with 3.90.2 and jumped to the last track in the cue, and it was early by only a few seconds.

That's a big difference. I burned the 3.92 encode as an audio cd with CDRWin, and it matched the original exactly.

I'll have a look at the MP3/Tag Studio 3.01, thanks.

update

I added VBR headers to both rips with MP3/Tag Studio 3.01, and that seems to have fixed the problem, more or less. Each track, when cued, seems to start slightly before the actual track, differently for each encode. If I leave the files to play through from the beginning, the files seem to change correctly.

I forgot to mention, both were encoded with the command line -F --alt-preset extreme


VBR may give better quality for the size, but this Winamp/mp3cue situation is awkward.

That's why I've personally given up on mp3cue (which can't work in a jukebox mode either) and rely on mp3splice output plugin to provide gapless playback.

By the way, does anybody have any feedback on whether lame --nogap does exactly what it's supposed to?

I guess to be sure you'd have to use EAC with the exactly correct ripping offset, encode with either:
lame --nogapout <dir> --nogap --alt-preset standard
or
lame --nogapout <dir> --nogap --alt-preset extreme

for example.

Then you'd decode with lame, which I presume is something like:

lame --decode --nogap file1.mp3 file2.mp3

(though --longhelp seems to suggest that --nogap is for encoding, and perhaps not decoding?!?)


I'm not sure the --nogapout <dir> thing is easy to do via EAC, and I haven't ripped a live or mix album for some time and tried to do it in a manner that would allow me to burn an audio CD-R. I might be tempted to use Musepack (MPC) or Ogg Vorbis (OGG) instead of MP3 when I do.

I guess it could be tried with a test waveform or sample that's split into two WAVs, encoded using --nogap, decoded back to two WAVs using --nogap then concatenated in an audio editor.

The resulting file could be closely compared to one that has been encoded (with --nogap to prevent a start-up difference) from the single WAV then decoded back to a single WAV.

Small differences in track length, waveform or even spectral view might well show up which could be attributed to deficiencies in the --nogap routine.

Regards,

Dick Darlington