[FFmpeg-devel] confusing trailing metadata for mpeg frames

[David Byron]

Michael Niedermayer wrote:

> when a mp3 file is read we seek to the end and parse all
> the tags, it shouldnt be hard to check durig packet reding
> where we are and skip the amount that we previously
> determined belongs to non mp3 data

Here's another take that is closer.  0001-* and 0002-* are the same, but
0003 puts the trailing_metadata_offset in MpegAudioParserContext.

Here's the new output from a slightly modified iterate_frames.c:

$ ./iterate_frames ape_and_id3v1_with_audio_5.mp3
[NULL @ 0x30e5010] Probed with size=2048 and score=51
[mp3 @ 0x30e5010] ff_mp3_find_trailing_metadata:
"ape_and_id3v1_with_audio_5.mp3": id3v1 tag at offset 3339(0xd0b)
[mp3 @ 0x30e5010] ff_ape_offset: "ape_and_id3v1_with_audio_5.mp3": APE Tag
contains header
[mp3 @ 0x30e5010] ff_ape_offset: "ape_and_id3v1_with_audio_5.mp3": 206 byte
APE tag at offset 3133(0xc3d)
[mp3 @ 0x30e5010] ff_mp3_find_trailing_metadata:
"ape_and_id3v1_with_audio_5.mp3": trailing metadata offset relative to
audio: 2507
"ape_and_id3v1_with_audio_5.mp3": frame 1: offset: 1024, stream index: 0,
pos: 0, size 626 byte(s)
"ape_and_id3v1_with_audio_5.mp3": frame 2: offset: 2048, stream index: 0,
pos: -1, size 626 byte(s)
"ape_and_id3v1_with_audio_5.mp3": frame 3: offset: 2048, stream index: 0,
pos: 1024, size 627 byte(s)
"ape_and_id3v1_with_audio_5.mp3": frame 4: offset: 3072, stream index: 0,
pos: -1, size 627 byte(s)
[NULL @ 0x30e62d0] mpegaudio_parse: giving up at offset: 3072 due to
trailing metadata
[NULL @ 0x30e62d0] mpegaudio_parse: giving up at offset: 3467 due to
trailing metadata
"ape_and_id3v1_with_audio_5.mp3": 4 frame(s), 2506 byte(s)

There one remaining issue I know of (and there certainly may be others) when
handling this file is that the offset I use in mpegaudio_parse isn't
correct.  I couldn't find a field in AVCodecParserContext or
MpegAudioParseContext from which I could derive the offset in the audio
stream (or even better, the offset in the file overall) of the buffer being
parsed.  I could use a hand figuring this part out.

The printf in iterate_frames.c prints all the fields seemed like they might
have this info but none seems to be correct.  This is potentially related to
the above...not sure.

Thanks again for your help.

-DB