[MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Tue Jan 17 00:56:18 CET 2012
On Tue, Jan 17, 2012 at 12:40:12AM +0100, Benoît Thébaudeau wrote:
> > > +static unsigned int id3v2_tag_size(stream_t *s) {
> > > + uint8_t tag[4];
> > > + unsigned int header_footer_size;
> > > + unsigned int size;
> > > + int i;
> > > +
> > > + stream_read(s,tag,2);
> > > + if(tag[0] == 0xff)
> > > + return 0;
> > > + header_footer_size = tag[1] & 0x10 ? 20 : 10;
> > > +
> > > + stream_read(s,tag,4);
> > > + size = 0;
> > > + for(i = 0; i < 4; i++) {
> > > + if (tag[i] & 0x80)
> > > + return 0;
> > > + size = size << 7 | tag[i];
> > > + }
> >
> > "tag" doesn't seem like really good naming to me.
>
> OK, then what would you like? "hdr"?
Can't think of anything. "body" maybe?
> > Personally I'd also rather go with either:
> > 1) Read all 6 bytes at once or
> > 2) Use stream_read_char to read one-by-one
>
> OK, I'll do that. Any preference between 1 and 2?
Not particularly, whatever looks nicer :-)
> > > + } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > > hdr[3] != 0xff &&
> > > + (len = id3v2_tag_size(s)) > 0) {
> > > + stream_skip(s,len-10);
> > > step = 4;
> >
> > Why accept hdr[3] values of 0 or 1 now? Aren't they invalid, too?
>
> http://id3.org/id3v2.4.0-structure
> "An ID3v2 tag can be detected with the following pattern:
> $49 44 33 yy yy xx zz zz zz zz
> Where yy is less than $FF, xx is the 'flags' byte and zz is less than
> $80."
>
> It does not say that the 1st yy can not be 0 or 1, but I don't find any
> information regarding ID3v2.0 or ID3v2.1. Do you think it's better to
> discard these major versions as non-existing? What about the possible
> future ID3v2.5 and above?
Let's keep it with your version then, though making such somewhat
unrelated changes is not ideal (e.g. for regression bisecting -
though the code is simple enough it should not be a problem here).
> > Also when failing id3v2_tag_size has read data and thus the data in
> > hdr is no longer in sync with the file position, so you must at least
> > set step to 4 in that case.
> > So I'm afraid it looks to me that squeezing that into the if made it
> > both uglier and wrong.
> > Just
> > > } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > > hdr[3] != 0xff) {
> > > unsigned len = id3v2_tag_size(s);
> > > if (len > 0)
> > > stream_skip(s,len-10);
> > > step = 4;
> >
> > Should be fine I think.
>
> No, that won't work either. If id3v2_tag_size fails, the tag signature is
> not present, so step should be 1. It's the stream position that should be
> changed in that case.
What are those "should be"s based on?
On error, step = 4 only has the meaning "resync hdr".
Yes, it means that if the file contains ID3 followed by something we
can't parse we will have skipped a few bytes unscanned.
Seems very, very unlikely to matter.
> Does stream_skip work with negative values, or should
> stream_seek be used instead?
Neither is possible or allowed if the stream is not seekable.
> OK, I'll do that. Also, the calculation of the duration uses movi_end instead
> of (movi_end - movi_start) at the bottom of demuxer_audio.c. Is it on purpose?
I'd say that is by mistake.
More information about the MPlayer-dev-eng
mailing list