Hi!

For some time now, I've been working on a lyrics plugin for winamp that will write to SYLT frames. The only major bug I have before releasing the first version is when I write the SYLT frame to the mp3 file, the bitrate of the file (I only use VBR) is changed to the nearest standard (128, 160, 192, etc ), dependig of the average bitrate of the song. The result is that the track lenght estimation (as shown in total track time) is no longer right. The song is playing ok and stops at the right time, but maybe something like 4.54/7:07. And this only happens in the empeg; in winamp, the time shown is correct.

To write in the mp3, I use a modified version of id3lib called vbid3lib.dll. I use the same steps as does Tony C in lrctool , and emphatic can read lyrics and timestamp correctly, so I guess I'm using the library correctly. Maybe I'm simply forgetting a crucial step. Anybody ever used this library to write to mp3?

How are the bitrate "written" in a mp3? How does VBR mp3 bitrate is specified? As I understand it, each frame has a different bitrate. But how does the player know which is the right average bitrate? or how does it know that the first bitrate it gets is the bitrate for THAT frame and not for the entire mp3?? On a wider note: Is there anywhere on the net I could find an "exploded" hex view of a mp3 with each part (header, frame, tag...) explained? I know www.id3.org, but I just can't seem to crossreference the documentation with a real mp3...

Thanks for your help guys!

Patrick

hi. try this

How does VBR mp3 bitrate is specified?

It doesn't actually need to be specified. Each frame contains its own bitrate (as shown in that site Customsex linked). However, there can be a custom Xing VBR header on the file that helps apps track their position in a VBR file. The empeg requires this special header in order to properly track into a VBR file. I'm guessing that your ID3-writing library is clobbering this header. There are available tools that can repair the header, I'm sure some of them are open source.

tony, the empeg requires the xing vbr header?
if it doesnt exist, what does that mean? we cant accurately step forward and backward through tracks?

if it doesnt exist, what does that mean? we cant accurately step forward and backward through tracks?

Correct. If there's no VBR header, or if the VBR header is wrong, then you will have trouble with any feature related to the time index on the song. For instance, you will get this problem.

let me see if i understand you correctly.
the empeg requires an xing vbr header, or just a correctly formatted vbr header? (or, is there no difference.)
i guess what im getting at is, if i encoded all my mp3s vbr with lame, not the xing codec, will they be correctly header'ed?

Yes and no. They will have a VBR header that is internally correct, but, due to a bug in LAME, it won't accurately represent the mp3 file. Any files encoded by a release version of LAME in VBR mode need to have their VBR headers fixed.

crap. and i just uploaded 7 gig of my newly encoded files
k

are the lame guys aware of this?

I wasn't aware of LAME creating bad VBR headers. I've encoded lots of files with LAME and never had a problem.

Perhaps it was the thing where LAME had VBR header trouble when using the "nogap" options? That was a separate issue as I recall.

Yeah. It's been fixed in non-release code. Check this changelog. The big one (to me) is taken care of in VbrTag.c version 1.60. You should be able to use Mark Lord's mp3tool to fix them.

Note that bitt is suggesting MP3Tool because it can be run directly at the shell prompt on the empeg player itself (if I recall correctly). In other words, you don't have to upload them to the player again.

But don't panic yet. Check and see if the files work OK in terms of track indexing first.

Actually, it wasn't a separate issue, it just presented itself more in nogapped files. (The issue is/was that the VBR header would report one less frame in the mp3 than there actually was. Not playing that one frame usually wouldn't be obvious unless it was supposed to flow into the next song seamlessly.)

Good point. In virtually all cases, the LAME VBR header is close enough. It's only very slightly off. But the reason I suggest it is because it's the only one that I know for a fact to work. There are probably others.

if i encoded all my mp3s vbr with lame, not the xing codec, will they be correctly header'ed?

To answer the question more realistically, yes. For all intents and purposes, there's a correct VBR header in LAME-encoded files.