New submission from yoav y...@monfort.co.il:
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 iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2645
