ID3 tags

ID3 tags

• moomooman123

  Hello Geraint,
  
  thanks for your answer! If you want you can try it out with the following file
  http://rapidshare.de/files/16617579/Alanis_Morissette_-_Ironic.mp3.html
  
  Play it in WindowsMedia Player and try it with graphedit (Render Media).
  
  Do you know if WindowsMedia Player uses other filters than graphedit
  
  Reiner
  
  

• ForgeAus

  Thanks a lot!
  
  Reiner
  
  

• krw

  I just looked at a few MP3 files with and without ID3 tags at the beginning, and mine all play correctly, but then they are all short tags.

  MP3 files are mpeg audio elementary stream. Strictly speaking, they don't need splitting -- you could have a push-mode source filter that delivers the whole stream directly to the decoder. However, they are normally handled by the splitter as that provides seeking/duration/random access and also provides access to the normal pull-mode source filter. So the mpeg-1 splitter in this case is handling the elementary stream as a special case.

  I expect that the splitter is handing the whole elementary stream to the decoder, including the ID3 tags. Or possibly the splitter is searching for a frame start, but finding a false frame start in the middle of the tag data. The recommended approach to finding a frame start is to look for the start code, parse the whole frame header and calculate the frame length in bytes, then look that far ahead and make sure there is a frame start exactly there. I don't believe the mpeg-1 splitter or audio decoder does that.

  The simplest solution of course is to move the ID3 tag to the end. Barring that, you could write your own splitter for MP3. This could be based on the sample mpeg-1 parser (and audio frame parsing classes) available at www.gdcl.co.uk. You would parse the frame headers and deliver only the audio frame data to the decoder. This is a fair bit of work for a few seconds of silence though.

  G

  
  

• Tim Murphy

  I took a quick look at the timestamps coming out of the splitter, and I think that is where the problem lies.

  The splitter timestamps the data going to the audio decoder, even though the mp3 stream does not have any timestamps in it. The data prior to the first audio frame is discarded, *but* the timestamp for the first audio frame is calculated using the byte offset from the start of the file, and the file's known bitrate. This means that unrecognised data prior to the first frame start results in a corresponding amount of silence before the audio starts.

  So an MP3 which has no tags and begins with the first frame has a starting time of 0 and starts immediately. An MP3 with some very short tags has a starting time of 8ms. Your example has rather more data, so the initial timestamp is calculated at 1.811 seconds.

  WMP uses DirectShow for some formats and some form of WMF for other formats. I guess it's clear that it does not use DirectShow for MP3 files.

  For workarounds: same as I said before. Either move the tags to the end of the file, or write your own parser or source filter. The simplest would be a simple push-mode source filter like the bouncing ball, using my audio frame class to only send the audio frame data and setting a 0 timestamp on the first packet (and no timestamps on subsequent packets).

  G

  
  
• ID3 tags