VBR ff/rw

That rings a bell now you mention it...
I rarely find myself using FF or RW when in the car, but I was trying it today when a track skipped while gaptest2 was running...
Don't panic!!! (in large friendly letters!) Nothing to do with the player, it was a badly ripped/encoded track I hadn't noticed before - guess I was multitasking when that slipped through

Geoff
---- -------
Got one of the first Mark 2 empegs...

Has there been any progress at getting FF & RW working with tracks encoded using VBR?
I noticed it is still a bit flaky in RC1, works with some tracks, not in others.
Aside from that, I haven't noticed any other problems with RC1 so far.

Hey guys,

I'm on a team writing a combo media organizer/player and we also use XAudio for our MP3 playback. I took it upon myself to fix the VBR problems that we were having with the stock XAudio stuff. We also had problems seeking to a certain point in the stream, until I found out some interesting information. There is a "VBR header" stored in the first frame of a VBR MP3 file. (At least ones encoded with Xing's encoder, but I'm not aware of another encoder that does VBR, and if there is one, I would assume they would implement Xing's header also)

Anyway, the VBR header stores information such as the total bit stream frames, the total bit stream bytes, the encoded VBR scale, and also an array of 100 bytes that range from 0-255, which allow you to interpolate the values so you can find "seek points" in the MP3 file relatively precisely.

If you guys are interested in this information, I can provide you the files you would need to implement this code as I did to get your player working with VBR files.

Later!

(O|||||O)

Our own VBR code works very well - however, this isn't shipping in the empeg-car yet, only in the OEM product.

Xaudio is more of a "black box" - it, in theory, does the VBR index and interpolation stuff. It doesn't seem to work well though, and we don't have source.

VBR will improve when Xaudio gets replaced.

Hugo