Well, I've been reading a lot on audio compression formats and decided to stay with LAME -alt-preset standard for the time being. I also planned on tagging all files I do myself using ID3 V2.

The problem is that when I play such an encoded file on my no-name portable mp3 player it tends to skip inside a song. So you can hear the first 30 seconds but suddenly it continues at 2:43 and then jumps to yet another place of the song. This is reproducable in a certain way so that I can say it happens to almost every VBR recorded song.

Now I've read here (click on the ID3V2 logo) that this might be a side-effect of using both VBR and ID3 V2:



For a test I removed the ID3 V2 tag of some of my mp3s and STILL I had some skipping in those songs (which I did not have with CBR songs).

Additionally the remaining time is not displayed correctly in Winamp 2.78. So when I make a playlist of all the songs in a dir I get the weirdest times displayed like 23:23 minutes for a song. Now whenever I play a song in the list the 'estimated' time gets reduced to something more reasonable like 3:48 but STILL it's not the exact amount of time as I only realize when I play the song till it's end.

So my question is:

- how come those files cannot be played correctly?
- how can I prevent this to happen?

TIA!

maybe when u removed the id3v2, u removed the xing header too(http://66.96.216.160/cgi-bin/YaBB.pl?board...0670714&start=8)
try to use vbrfix: http://www.willwap.btinternet.co.uk/programs/vbrfix.htm

[edit]and, plz, dont double post [/edit]

Actually I think that the Xing header wasn't constructed at all when I made the mp3 with Audiograbber and LAME 3.92. I've used VBRfix on the files that still had their ID3 V2 tag and after that the remaining time was displayed correctly.

So the question is, wether it's a bug of Audiograbber or LAME or if they don't work together as they should. Gonna ask in the Audiograbber forums first.



Hmmh, are these two boards connected in any way and do they share the same audience? I thought these were too seperate boards with only a few common users so a post on both should be legit and increase the number of potiential helpful answers...

Well ID3v2 is not random data, it's data that CAN'T contain a syncword. So the file is fully playable.

And now Winamp handles ID3v2 correctly. It even tells you the position of the first header in the file (the Xing frame if there is one).

disable encoder uses stdin/stdout or something like that.

As I've just read in the German Audigrabber forum this is some kind of a LAME bug. When using it to directly grab mp3s from CD it does not write the Xing header correctly. Only when I use a temporary wav file and then encode to mp3 the header is written correctly.

So my question is now: can this be fixed (and who would I have to ask about it) or is this by design? I mean, how does LAME know when and in which frames of the file to write the Xing header when it does no yet know how large the file will become? Does a Xing header have to be in every x-th frame or what?

Thanks again!

I have never had any problems like this, though I know of someone who has; I use Exact Audio Copy with LAME 3.92 (and formerly 3.91 & 3.90).

Some tagging programs might not recognize the VBR header and try to overwrite it or screw it up somehow... though this is only a guess. Can anyone back me up on that?

EDIT: Also, I don't think a missing VBR header would cause the files to skip. I mean, M$ WMP doesn't read Xing headers correctly, but still plays them back just fine. I have heard that some MP3 portable players just don't support VBR as they should.

Quite possible but I did not use any specific tagging program but Audiograbber did it while generating the file.



Actually it doesn't. I mean, playback works as with Winamp but the total time of the file is not displayed correctly even when the file is played through. I got a song of 4:15 and Micros~1 Media Player says it's 1:52 even though it plays for the whole 4:15 mins. So you seem to have tried only regular VBR mp3s.

As said before, the bug is reproducable so if you've got some time to waste try it out with Audiograbber. I don't wanna enter any discussion about why EAC is or is not better than Audiograbber. I just wanna know who of the LAME team I would have to mail about that header bug. Do those guys read this forum, cause they linked to it from their pages...

this is not a lame bug! It is simply impossible to write something into the beginning of a file after it is encoded, don't you think . A code change could do this, but this would cause longer encoding times and something like an info cache or text file where the information is saved and then written to the file!

You could use vbrfix to fix the mp3, but i don't know if you want to do this. Simply uncheck the stdin / stdout boxes and use the other suggestions made in the german AG forum!

Well, the ID3V2 header is also at the beginning of the file. Whatever, as I've said before in this thread this 'bug' might be by design simply because the mp3 is in the process of being built when the Xing header is added. So I'd like to ask those LAME guys (or anyone else who does know about stuff) where the Xing header is written into a VBR mp3. Is it at the beginning of the mp3, every mp3 frame or only several mp3 frames (every 10th or so) when it is a VBR mp3.

IMO the adding of the Xing header should work in any of those three cases even in runtime. Cause if you can write a normal mp3 frame header during encoding you can also write a Xing header, right? Of course, if the Xing header has info about the complete file it could certainly only be added at the end of the whole encoding process.

And that's what I'd like to get cleared up! Personally I think the most convenient way of ripping VBR mp3s is straight from CD to mp3 without having to use any temp wav files or something....

Well, the ID3 Tag doesn't need information about bitrate and so on and can be added right at the beginning because the needed information is already in AG or EAC!

The Xing Header can only be written after the was encoded and the exact bitrate was determined. To my knowledge the xing/lame header is in front of the mp3!

Then again, how could you add something to the beginning of a file, when the file was already written. Its just impossible!

btw, where is your problem with temporary wave files ?

Well, there's no exact bitrate since it differs from frame to frame, that's what makes an VBR mp3, right? Still, I agree that some info might be needed that is only available when the whole file is done. That's why I'm desperately hoping for someone with enough knowledge of the Xing header and the LAME encoding process to drop in to shed some light on it.



Definitely not impossible. Did you ever manually add an ID3V2 tag to an untagged file with Winamp? The whole data is moved and the tag added in front of it, that's why it takes so long.



Lack of convenience, additional time, additional hd space.

exact bitrate should be average bitrate in my sentence



well, then you can directly go over temporary wave files. Should be a bit faster!



well, if you add the header afterwards with vbrfix or something like that, the time benefits wouldn't be that big! An 40 - 50 MB shouldn't be the issue!