Hi Matt,

> The frame size roughly equals 365.71, or 365 because it is being stored in an 
> integer. All  is good until I advance to the next frame, which the program assumes 
> is going to be at point 0x16D (365 in decimal) in the file. When I seek to that 
> position, I am starting to read the second byte in the header, not the first. The 
> header actually starts at 0x16C (364 in decimal), one byte short of my frame size. 
> (I use a hex editor while I am debugging so that I can see exactly what my program 
> is reading.) The header indeed starts at position 364 in the file.

you did not ignore the padding bit, did you? if padding is true then
your framesize is one byte larger than usually. 

Send me a mail if you need sourcecode...

HTH
Chris


-- 

Christoph Rupp
Leiter Softwareentwicklung
_____________________________________
umc - united media company GmbH
Bgm.-Aurnhammer-Str. 26-28
86199 Augsburg

Tel: +49 (0)821 90676860
Fax: +49 (0)821 90676869
web: http://www.umc-web.de

_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder

Reply via email to