mIRC Homepage

Fixing the ID3v2 bug once and for all.

Posted By: Scorpwanna

Fixing the ID3v2 bug once and for all. - 24/05/07 04:43 AM

I dunno how many times I've ran across an mp3 that just wouldn't display it's information correctly when all other programs out there do. People claim some VBR's are at fault, some think random CBR encodings cause the problem. But my understanding so far is the ID3v2 that causes most of these problems and it's not necessarily the VBR or CBR encoding. It seems to confuse mIRC about the actual information about the file's bitrate, length etc... 9 times out of 10 removing the ID3v2 info solves most of these problems.

Some would argue about the Windows MCI not reading the file right through mIRC. But how many of us are tired of that excuse?

So for a suggestion, maybe fixing the ID3v2 bug that we've always had to try and bypass with outside help from dll's or advanced scripting techniques.

Edit: Here's an example I just got through testing.
the file test.mp3 is 128(kbps) 44100 Stereo 24 seconds with no ID3v2 tag data.

Played in mIRC echoing the information normally shows this:
playing test.mp3 128kbps 44100khz Stereo 0:24

Using Winamp to quickly add some ID3v2 information only giving the title the information of "a". Playing again echos:

playing test.mp3 192kbps 44100khz Stereo 0:16

In Winamp again giving the ID3v2 information typing in the title field "this is a test". Playing again echos:

playing test.mp3 224kbps 48000khz Stereo 0:14
Posted By: starbucks_mafia

Re: Fixing the ID3v2 bug once and for all. - 24/05/07 12:19 PM

Well I've got absolutely no idea why you've posted this in Feature Suggestions and not Bug Reports, but whatever, onwards...

I've got about 600 MP3s currently sitting on my computer right now, all of which use ID3v2 tags set by several different programs. I am not aware of any that mIRC reports incorrectly. Clearly your "ID3v2 is the problem" assumption is incorrect. There is more going on here. Unfortunately you haven't included any practical information to reliably reproduce or otherwise determine the problem:

  • What program(s) (and what version(s)) were the MP3s encoded with?
  • Which exact version of Winamp are you using to add ID3v2 tags?
  • Do the MP3s have any other metadata tags attached to them (eg. ID3v1 or APEv2)?
  • What does Windows Media Player report?
  • What version of Windows Media Player do you have installed?
  • What OS are you using?
  • Are you using $mp3() or $sound() in your tests?
  • Does mIRC correctly return the ID3v2 tags when using $sound(filename, N).tag?

And give us some links to actual samples that don't work!
Posted By: Scorpwanna

Re: Fixing the ID3v2 bug once and for all. - 24/05/07 07:20 PM

Added to the suggestion area because for years it's been a bug and hasn't been attempted to be fixed.

  • To encode all my mp3s, I use Goldwave and Fraunhofer IIS MPEG 1 Layer-3 Codec (professional) that allows up to 320kbps 48000khz Stereo
  • In this test I used Winamp version: 5.32 to insert the ID3v2 data.
  • MP3's do not have other metadata tags attached. Not even ID3v1, which is located at the end of all MP3 files anyway and is of no consern.
  • Windows Media Player 11
  • Windows XP
  • Both $mp3() and $sound() were used to test this.
  • Yes using .tags and tag returns the correct info but that's not what this post is about.


testmp3.mp3
No ID3v2 data returns: 320kbps 44100khz Joint Stereo 0:22

testmp3B.mp3 (same mp3 as above but given some ID3v2 data using Winamp
With ID3v2 data returns: 160kbps 32000khz Stereo 0:44

ID3v2 data can contain up to 256MB just in itself, so I'm wondering if mIRC's identifiers just give up after a certain attempt at reading the files.
Posted By: starbucks_mafia

Re: Fixing the ID3v2 bug once and for all. - 24/05/07 08:20 PM

Well the first thing that's clear is that the ID3v2 tags don't appear correctly under mIRC because they're encoded as UTF-16-LE, which mIRC doesn't correctly handle resulting in null bytes converted to spaces.

Which would appear to be the problem: Unicode tags. I can now recreate the issue in any other software by forcing the tags to be Unicode.
Posted By: Scorpwanna

Re: Fixing the ID3v2 bug once and for all. - 24/05/07 09:09 PM

What other software do you use to add ID3v2 tags? I've only ever used Winamp frown.

I thought a ID3v2 tag was always written to the beginning of an MP3 the same no matter what. Hrm, that's interesting the Unicode. Perhaps maybe fix that bug then smile?
Posted By: CtrlAltDel

Re: Fixing the ID3v2 bug once and for all. - 26/05/07 05:14 AM

Originally Posted By: Scorpwanna
What other software do you use to add ID3v2 tags?


ID3-TagIT
Posted By: starbucks_mafia

Re: Fixing the ID3v2 bug once and for all. - 26/05/07 09:24 PM

Quote:
What other software do you use to add ID3v2 tags?

Well one which I bet a lot of other people use is iTunes. From the looks of it that'll only use Unicode for the tags if there's a character which can't be represented by the ISO-8859-1 encoding, which is why I never have any trouble.

As far as other programs I've used, there's about a dozen different audio players, tag cataloguing apps, and custom scripts using open libraries/modules I've used. All of them have used ISO-8859-1 tags aswell by default. I guess this will become more and more of a problem though as Unicode continues to get adopted by more and more programs (as it should).

The ID3v2 tags must always be before the audio data, it doesn't matter what program you use.
Posted By: Khaled

Re: Fixing the ID3v2 bug once and for all. - 31/05/07 04:02 PM

Thanks this should be fixed for the next version.
© 2022 mIRC Discussion Forums