id3 library

[ImDaFrEaK]

Ah, I broke the code last night bro and now its ON. I will have my own ID3v2.4 tag reader/writer .dll out soon and it will be running from the .NET 2.0 framework. I finally got the crap figured out last night and now I am in the process of building the .dll. Anyone hit me up on Y! or e-mail if you'd like to get the latest on it.

 

[ImDaFrEaK]

Well, lots to learn.

Come to find out ID3v1 is the best standard there is for reading and writing mp3 header info, only problem is it's limited. Only limited to what it needs to be anyways. Check this, you get 7 msgs from ID3v1 Title, Artist, Album, Year, Comments, Track, and Genre(in that order). That's really all you need. Well, ID3v2 and up offer alot more info, the only problem is it isn't nearly as organized. There is a proposed standard out there but nothing perfect. Anyways, ID3v1 goes at the end of the .mp3 and ID3v2 and up goes in the front. Alot of information is there and it's pretty wasteful. It's alot of extra garbage added to mp3's increases the file size and causing errors. And in alot of cases it's got the same info 2 or 3 times. Programmers aren't ready to decide. Not to mention the 7 listed items in the ID3v1 are printed again in ID3v2. mp3's can potenionally be a little smaller if it wasn't for this crap. However; it seems not stoppable. I have written my own ID3v1 reader/write now and it's glitch free(well, so far anyways, hehe). I know I was requesting v2 in this but that was before I realized what the difference was. I am now working on the read adn write for v2 and up to include a clean up that removes the trash and duplicated entries to increase mp3 performance and lower file size. This is redicuous what I have found and to be honest it's completely un organized. Nobody should use v2 and up until it get's a for sure game plan as to how to tag it. Developers are crowding mp3's with crap and screwing them up. It's not an experiment it's music.

 

[ImDaFrEaK]

ID3v1.1 Tag Reader / Writer

I have finished the Tag Writer. Here are all of the properties. It's super easy to use.

FileName

Title
Artist
Album
Year
Comment
Track
Genre

All you do is Set the FileName of the Song you want to use....

[SIZE=2]
G3_ID3.FileName = [/SIZE][SIZE=2][COLOR=#800000]"C:\My Songs\Intro.mp3"
[/COLOR][/SIZE]

Then Read off the other Properties....

[SIZE=2]
TextBox_Artist.Text = G3_ID3.Artist
[/SIZE]

To change the information just change the property...

[SIZE=2]
G3_ID3.Year = "2005"
[/SIZE]

It's automatically saved into the MP3 each time you change the value....

I've tested it several times and it works great.

For Track and Genre remember you can't go below 0 or above 255 becuase it's simply 1 byte from the mp3 tag. There is also an Enumeration for the Genre Property to help you see what Genre's are what and it ranges from 0 to 145 with pre-assigned Genres described as standard for ID3v1.1 .

If your interested in this .dll please e-mail me at <email-removed, use private messages or forum>


I will look into the ID3v2 a little more and if anyone is desperate for it I will work harder, but ID3v1 will always be there and as you can see it has alot of information on it. I would wait until ID3v2 became more standardized before I worried about it. I'm not worried about it anymore now that I understand what is going on. ID3v1.1 is plenty.

Thanks

 

[JohnH]

I split the thread to the Testing/Quality Control/Debugging forum since you seem to want feedback on your id3 library, is the source code also available by contact?
Also removed the email address, best to avoid those mailspiders, there is Private Messages for the forum users and regular forum usage.

 

[ManicCW]

but winamp has that possibility integrated.

 

[ImDaFrEaK]

So winamp lets you use the dll to make your own mp3 programs ect? Anyways, I found several several several forums and sites listing problems and glitches with winamps ID3 tags. I don't think they got their crap down pat.

To answer JohnH, No the source code is only available to partner developers. I now have copyrights on it and plan to build greater things with it. The dll itself is available to any developers.

 

[cjard]

note that there was ID3v1.1 which reserved the last 2 bytes of the comment field for track number. this actually consumes 3 bytes from the end of the comment as the third comes in as a null character to inform the reading app that the comment is finished and the next 2 bytes are track numbers

i was saddened that such a lame implementation was allowed to exist, it's a poorly thought out kludge and i came up with a much better solution in my head, that the year field (4 bytes wastage just to store an int that would be in the range 1900 to maybe 2100) could be adjusted to store year (1900 to 2156), disc number (0 to 128), track number (0 to 128 though red book spec limits tracks on a cd to 99) and around 10 boolean flags that were user defined.. and still only consume 4 bytes

i made a test version of my tag library as a proof of concept for me, but i never bothered chasing others up to see if they would be interested..

along the way i learned quite a bit about ID3 tagging and i still prefer ID3v1 to ID3v2 for reasons of hard disk work - ID32 are stored on the start of the file, requiring that the entire file be rewritten (the file is appended to the tag rather than the other way round). the debate i had with the standards writer of ID3v2 at the time was:
him> id32 is better because when streaming it, the tag is read first and can be broadcast before the song, not after it
me> and of course no webserver out there in the world has a random access file system..

i raised other points like, an id32 tag can potentially be longer than the file itself, contain pictures, zip files, exes and other things (so theoretically an id32 tag can contain a virus) and i still dont believe id32 is worthwhile but i dont bother so much any more..

its a cert that few people will use a library that only tags id31 though, so you might have to get your xml loving aspects of your personality out yet...

the way id32 slips inside mp3 blocks so as to appear invisible to incompatible players (they play as silence) is rather clever though.. one of the tag's plus points. i'd have loved to see ID31 go further, to variable length simply by writing a length variable at the end of the file, of the number of bytes to skip back to find the start of the tag.. no matter

good luck with your tag project, and if you need any help, let me know

 

[JohnH]

I join in on supporting v1 over v2 for the consistency and easy of use for mp3 files, also for the excellent ground work on trying to create a industry standard for genres that can't be misinterpreted, something the MS mediafiles seems to have missed out on completely. Id3 v1 is limiting when it comes to string fields, but v2 was made for any mpeg media file and any type content descriptions so its bound to be over the top for most limited file/content uses.

 

[ImDaFrEaK]

I learned also that ID3v2 is a waste and I despise it. I will not use it and I have converted whatever players I have currently running to only use ID3v1. I also gave up on ID3v2 and built my own v1 tagreader. v1.1 to be exact and it works great. However; as far as having 3 bytes for track I only use 2. You only need one byte 0-255 tracks. And the null byte is a waste. We know to count the exact amount already. I definately support v1 and that's all I use. I do apologize however not to accept your offer to help with the new standard v1.2 which changes the use of the track and year bytes. Personally there is enough information already listed and to try and build a new standard now would wreck what we have so far. The standard we have now could be optimized even more yes, however; to change such a thing effects the whole world in use of mp3s and their use of it's current standard. I would vote though to get rid of ID3v2 + b/c it has wrecked mp3s and their file size.

 

[cjard]

sorry.. i made an error in my post.. im sure i edited it, but it doesnt seem to have saved the changes.. i meant to say that track uses 2 bytes from the comment (as you know), but i do think the null byte is necessary because there isnt any specified way to tell the player that it's a 1.1 comment. if you didnt include the null byte, the player could reasonably assume it was a 1.0 comment, drop the track number and show a comment like "ripped by some dude some where♪" or some other junk character on the end..


id32 does have its advantages, but i think perhaps the biggest mercy that we were granted with id32 is that noone is interested in using it for anything more than what id31 holds. winamp puts a few extra fields in or something, but very few taggers that i have seen, have options for e.g. embedding the entire hi-res cover artwork for an album (i.e. 17 megs of jpegs) in every tag on every file.

these days what i tend to do if i ever bother tagging (i dont care much any mopre after i lost my whole collection of ~28000, i cant be bothered re-tagging the new ones - i just let EAC put whatever it likes out of freedb in there) is fill out the id31, then have some tag program like mp3tagstudio copy the details over..

so add me to your list of people who think that id32 was a step too far, even though it does have some great features.. its not going away soon, i think

 

[cjard]

incidentally, one of the arguments the author made for id32 was that "it's good to have the entire file re-written. data is stored magnetically, and it degrades over time. re-writing it renews the magnetism and improves the likelihood that the data will continue to be available"

hmm

 

[ImDaFrEaK]

Well, you might say that the null byte is neccesary but I don't use it with my tag reader. Of course I keep the byte null not to interfere with other tag readers but my reader simply counts the bytes out and uses them. So even if that byte wasn't null my reader would not use it. Only down side is, like you were saying, we don't know if the next byte is supposed to be track number or letter. Well, my reader makes it a track number and if the user disagrees then they can change it at run time. It's the easiest way to continue the switch from 1.0 to 1.1. therefore if the that byte was meant to be the letter "g" at the end of some comment it would become track 103. The user, seeing this at run time, simply changes the track number if they know what it is supposed to be. If not, then sooner or later it will passed on to someone that does, via Gnettulla or whatever. As we have learned, mp3's are very flexible but yet cluttered and butchered. So I am very glad to read that many fellow developers prefer ID3.1 as supposed to .2.

 

[cjard]

Well, you might say that the null byte is neccesary but I don't use it with my tag reader. Of course I keep the byte null not to interfere with other tag readers but my reader simply counts the bytes out and uses them. So even if that byte wasn't null my reader would not use it. Only down side is, like you were saying, we don't know if the next byte is supposed to be track number or letter.

AFAIWA, the general rule is:

if comment[29] <> 0 and comment[28] = 0 then
 'it's an id311 tag
else
 'its an id30 tag
endif

so the identifying notion for id311 is that the last 2 bytes of the comment are null followed by non-null. in all other cases they denote a id31 tag, whatever it is padded with (should be nulls but some old taggers use spaces)

 

[ImDaFrEaK]

Yeah, I know how to detect the difference, I was just saying that I intentionally don't. I read all bytes and set the track even if byte 29 is not null. I am simply forcing the merge. And what I meant was it would show a bad track number if it wasn't meant to be there but the user could easily fix that.

 

[cjard]

how bizarre! i thought your intention was to create a library for others to use? tbh, i wouldnt use it if i had to implement a workaround and guess the id3 version. i very much doubt that v1.0 is used any more, but i still wouldnt make the assumption..

also you mentioned that every time the property is changed it is wriotten to the file.. do you feel that doing more than one write is a waste of time? i.e. if i sequentially set album, title, artist, track,year, genre and comment i wrote to the file 7 times.. would rather do it once!