2

I created my own MP3 frame parser. I can read each frame individually if I do it sequentially.

My problem is that I have yet to figure out how to find the byte offset of the nth frame (without having to read all the prior frames).

CBR makes this process easier, but I still don't know how the padding bit factors in.

For example, take a file that has the following info:

Total file length:  4916595

===== ID3 METADATA =====
ID3v2 header length:  143

===== MP3 FRAMES =====
Version: MPEG Version 1
Layer: Layer III
Error protection: No
Bitrate: 192
Frequency: 44.1

Some frames have a byte length of 626 and other frames have a length of 627.

Let's say I want to find the 100th frame, I can't simply do 100 * 626, nor can I do 100 * 627.

How should I factor in the padding bit in my formula to find nth frame's byte offfset?

Maxime Dupré
  • 5,319
  • 7
  • 38
  • 72
  • You still have to read through the offsets frame-by-frame, because there's no way for you to truly know it's CBR. A differently sized frame could be dropped in arbitrarily. Also, some encoders do quirky things at the beginning of the file. So, if accuracy matters, read each frame header. Fortunately this goes pretty quick these days. – Brad Dec 24 '22 at 02:02
  • I know it's a CBR file because I'm dealing with files I have created with FFMPEG and explicitly set the bitrate My parser correctly also identifies the ID3v2 header, so I know this offset. I just need to be able to predict in advance which frame has a padded bit – Maxime Dupré Dec 24 '22 at 19:27

1 Answers1

0

Probably MP3val solves your problem. Once installed, run:

mp3val -f file.mp3
razimbres
  • 4,715
  • 5
  • 23
  • 50