[ctoth]

What

MP3s that carry an info header now start and end where their source did.

• The Xing/Info header frame at the front of the file is no longer played.
• When the header comes from LAME or libav (encoder name LAME, Lavc or Lavf), the encoder delay and end padding it declares are trimmed too.
• MP3s with no info header decode exactly as before.

Why

go-mp3 (and Beep's wrapper around it) decodes every frame as audio, including the header frame, and does nothing with the delay fields. Measured through decodeSound on a 0.2 s tone encoded with LAME at 48 kHz:

	frames decoded	source frames
before	12672	9600
after	9600	9600

The extra 3072 frames were 1152 of header frame, 1105 of encoder plus decoder delay in front of the sound (47 ms late in total), and the rest padding after it.

Notes for review

• The fix is all in internal/audio/native/mp3.go. mp3InfoTrim parses the header from the bytes decodeMP3 already holds; window drops the leading frames by decoding and discarding them, not by seeking, so the remaining samples are identical to a straight decode.
• The decoder delay is taken as 529 frames. The tests pin it: they compare the decoded tone to the source formula with a tolerance of 0.04, and one frame of misalignment is an error of 0.08.
• A header from any other encoder loses only the header frame. A header that would trim the whole stream is ignored with a warning.
• The two fixtures under testdata/ (2.1 kB and 3.0 kB) were made with ffmpeg's libmp3lame from aevalsrc sines. ffmpeg's own decoder returns 9600 and 8820 frames for them, the same lengths the tests expect.
• TestCharacterizeMP3 still passes unchanged: its fixture has no info header.
• Not covered: MPEG-2/2.5 files and files with a CRC. The offsets for both are in the parser, but no fixture exercises them.

Testing

go test ./... passes; golangci-lint run ./... (v2.14.0) reports 0 issues.