New submission from yoav <[email protected]>: ff_id3v1_read seeks to the end of the file in order to read the id3v1 tag. Once done reading it seeks back to offset 0. This is a bug since in many cases we were at a different offset (for example after reading an id3v2 header) before calling ff_id3v1_read. Example: In the attached file there's an id3v2 header with no relevant data (just a header with no actual album/artist/... metadata). After this header there's a VBR header (LAME's 'Info' header). In the current mp3dec.c we call ff_id3v1_read since we didn't find any interesting data when reading the id3v2 header, then before ff_id3v1_read returns we seek back to the start of the file (bug!), this prevents us from finding the VBR header since we're back at the beginning of the file instead of being after the id3v2 header when looking for the VBR headers. File 'y.mp3' not attached - you can download it from https://roundup.ffmpeg.org/file1360.
---------- files: y.mp3 messages: 13815 priority: normal status: new substatus: new title: ff_id3v1_read seeks back to start of file instead of previous offset topic: avformat type: bug ________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/issue2645> ________________________________________________
