Slashdot Mirror

Beyond that, the submitter is sort-of uninformed about MP3 tags:

I checked, and I found I couldn't access the information using an ID3 tag editor, but using Notepad I found my email address stored inside the audio file itself.

There are a ton of defined tags out there that ID3 tag editors don't deal with at all.

Additionally, there's a whole namespace of possible "custom" ID3 tags any vendor may define. Apple might do this for your iTunes account info. An ID3v2.4 frame may be called "TXXX," where the "X"s are any alphabetical character. Apple could use TUSR to denote the iTunes username (i.e., email address). http://www.id3.org/id3v2.4.0-frames

I have a large variety of MP3 files to better understand the file format for possible future creation of my own codec... Does that work for ya?

Not when you can accomplish the same thing without violating copyrights.

http://en.wikipedia.org/wiki/Wikipedia:Sound/list
http://www.digitalpreservation.gov/formats/fdd/fdd000012.shtml
http://www.id3.org/mp3Frame
http://www.dv.co.yu/mpgscript/mpeghdr.htm

Wrong! :D

ID3 version 2 : http://www.id3.org/ID3v2Easy

MP3 players these days commonly support ID3 tags

One ID3 tag (type CRA) can specify encrypted audio. But it also specifies that part of the stream can be a unencrypted sample.

So satisfy the law. Use DRM. Use MP3 with embedded CRA tags. Make 99.9% of the stream a free preview. Encrypt a millisecond ocasionally. Pick a moment of silence.

I suggest using the 'XOR with a Zero' code.

See section 4.21. http://www.id3.org/id3v2-00.txt

upon first installing itunes and importing my pre-existing tree, itunes decided to move the entire tree to a different location. seems like a change to me. apple does not use id3 tags correctly. why do equalizer settings clobber my comment tag? that's what the equalizer tags are for. sounds like they use a NON STANDARD TAGGING SCHEME.

the official standard (http://www.id3.org/) only defines 80 genres.

Nullsoft added a further 45 to the list, but these remain 'unofficial' additions.

you can see the whole list at http://puremango.co.uk/id3lib.txt

I agree that ID3 is limited, but I'm not sure its limitations are as dire as you paint. ID3v2 (http://www.id3.org/id3v2.4.0-frames.txt) addresses some of the "what year" concerns you mentioned.

One well-adopted "standard" (which isn't a standard at all) is ID3 (and its successor, ID3V2), the standard for tagging files with metadata.

The interesting thing here is that it is as standard proposed and written in the spirit of Open Source -- its development is moderated by a core group of loosely-knit volunteers, and anyone can contribute to the discussion.

It has been adopted by practically every developer -- commercial, open source, Joe-in-Basement, etc. -- of multimedia software, even Microsoft.

No standards body (IEEE, IETF, ISO, NIST, W3C, IANA, etc.) has accepted it as a standard; to my knowledge it has never been submitted to any organization as a proposed standard.

By community involvement and acceptance, it has become a de facto standard, and for the most part everyone plays by the rules.

I was thinking about something like this myself. Basically, what I'd like to have are two flags:

1: Never play unless I explicitly say so.
2: Don't include in shuffle.

The first one I'd use to flag interviews etc. that are sometimes included on albums. Is not necessarily bad content, just something that you don't generally need to hear multiple times.

The second one is for flagging things like Beethoven's 9th. It's really good music, but you don't want 67 minute long pieces in a random playlist.

I currently just use the 1 and 2 star ratings for this, but it's not really ideal. It's too bad (but understandable) that iTunes has no option for looking at TXX frames or I could implement it in a better way.

MP3 files most definately have frames:
http://www.id3.org/mp3frame.html
http://www.dv.co.yu/mpgscript/mpeghdr.htm

Q: Where is an ID3v2 tag located in an MP3 file?

It is most likely located at the beginning of the file. Look for the marker "ID3" in the first 3 bytes of the file.

If it's not there, it could be at the end of the file (if the tag is ID3v2.4). Look for the marker "3DI" 10 bytes from the end of the file, or 10 bytes before the beginning of an ID3v1 tag.

The ID3v2.4 specification has tags for just such information.

id3.org contains good reference material for both id3v1 and id3v2 tagging information. There is also an overview of ID3 tags implementations for C/C++, Java, ActiveX and Delphi. The implementation page also has pointers to most of the sources referenced in the excellent IBM article.

id3.org contains good reference material for both id3v1 and id3v2 tagging information. There is also an overview of ID3 tags implementations for C/C++, Java, ActiveX and Delphi. The implementation page also has pointers to most of the sources referenced in the excellent IBM article.

id3.org contains good reference material for both id3v1 and id3v2 tagging information. There is also an overview of ID3 tags implementations for C/C++, Java, ActiveX and Delphi. The implementation page also has pointers to most of the sources referenced in the excellent IBM article.

id3.org contains good reference material for both id3v1 and id3v2 tagging information. There is also an overview of ID3 tags implementations for C/C++, Java, ActiveX and Delphi. The implementation page also has pointers to most of the sources referenced in the excellent IBM article.

Sorry, but that's incorrect.

The ID3v1 tag, according to this document, was "a fix-sized 128-byte tag that would reside at the end of the audio file. It would include title, artist, album, year, genre and a comment field." these are fixed-width fields. As an example, a trackname can be a maximum of 30 chars long.

This was not enough (as anyone who listens to Godspeed knows :)), and it was completely replaced with a real tag-based system. Each ID3v2 tag has a header with a type and a length, etc, so that they can have variable length. They're placed at the beginning, as MP3-players usually look for the proper mpeg-patterns before playing. No pops...

Written partially from memory. Anyway, back to coding bsp-trees. Please kill me.

as Apple apparently uses its own tag format

Apple uses ID3 v2.4 (which added album artwork support).

Your other media players are written by companies that apparently don't care about standards.

It adds the iTunes Music Store, and lets you store album art for each song. (I'm not sure WHERE on my hard drive those images are stored)

Much of what you describe here is already part of ID3v2.

Including lyrics would be a GREAT way for the music industry to differentiate their mp3s from the home-ripped ones currently in circulation..

Please refer to the spec, ID3v2, rather than some notion about an ancient ad-hoc version.

What about ID3v2?

--

y'know, what would happen if somebody were to make an mp3 of something that didn't sound like DeCSS, but had the text or one of the images from here in its id3 tag?

id3 tags are in MP3 file because they're part of the MP3 file format spec.

NO! This claim is completely wrong. Please don't go around spreading such misinformation.

A brief glance at even the id3 site's own history page shows that id3 tags were created by a freelance programmer independently of the MPEG audio standard.

I hate id3 tags and do everything possible to strip them out of my own mp3 files. Yes, metadata is a thorny problem, but violating the MPEG audio standard and pretending the result is still an mp3 file is a cure worse than the disease.

I also have practical reasons for avoiding the id3 tag: most of the music I listen to is not of Western origin, and does not fit well into the Title/Artist/Genre classification system of the id3 one-trick-pony. And I'm not even getting into the problems that id3 and support programs have dealing with multi-byte charsets.

To keep this post vaguely on topic, I should point out that Eazel is working on ways to handle and present metadata without the need to break standard file format specifications. For example, take a look at the album screenshot with metadata consisting of the CD cover picture. I guarantee you that the CD cover picture is not embedded into the individual mp3 files.

The MP3 format is designed for pop music; its only ID fields are "artist", "album", and "song". Classical music does not have "albums", and "songs", and has at least two artists per recording. It also needs more specialized fields such as "conductor", "soloists", "orchestra", "opus number", and the like.

(This is a response to numerous other replies on this thread)
MP3's, whether or not they have a true 'header'
such as an ID3v2 tag, are a streaming format by
nature. The mp3 itself is composed of individual
frames, each of which is less than 1/50th of
a second long. For VBR encoding, the encoding
changes from frame to frame. The frames
can be easily identified, even in a hex editor...
they all begin with a 'sync' signal,
being FFFX, byte aligned. Once you figure
out how long the frame is, from the data in the
frame's header, it's very easy to cut out parts frame by frame.
here's some perl code I wrote a while back for parsing an mp3 apart...
I used it to create a simple mp3 editor. (Can't find that right now).
Also, for those interested, you might want to go to ID3.org ,
which is where I got most of my info.

Just so this response stays on topic (hahaha),
I don't see how they could do this without
making it REALLY easy to strip them,
unless the ads were overlayed on top of the
audio data itself. In that case, some sort of
stripper (like the karoke plugins for XMMS)
out to be able to strip out the data.
In any case, as long as I can strip them out,
I love this idea... just like banner ads,
they make people money, and don't bother
me at all.
If anyone gets an actual example of such an
mp3, please post it here (or atleast email it
to me!).
-Slackergod

This, I think, is the core of the matter. It's also interesting that this is not, by and large, what the labels are saying. They're talking mainly about "artists' rights", while the artists figure they worked hard, and really ought to get paid, thank you.

So, I'll lay out the idea below again. I've run it through various discussion forums at mp3.com a couple of times, and nobody really noticed. I thought it was simple and straight-forward, but maybe it really is revolutionary...

First - you can't digitally protect music. If you encrypt it, then you have to decrypt it to use it, and unless you're using secure hardware, that protection won't last long. [see deCSS] You also can't use watermarks for that reason - if someone can identify the watermark, then they can remove it. You can identify music using watermarks, but only to determine that piracy and illegal distribution has taken place. You can't actually distribute the watermark check (see above). And if all else fails, someone will just digitize an analog copy.

It's beginning to look like it's digitally hopeless to try and protect music, until you realize that's not the goal. You just want to pay the piper. Literally.

Everyone's worrying about music distribution, but as MyMp3 and Napster show, the distribution problem is solved. We're just waiting on a little more bandwidth and disk space, and it will be solved for everybody forever. The distribution cost will be so low, that you would pay more to control the distribution than you would to actually distribute the content.

So, rather than worry about a solved problem, how can we pay the musician? The other time-honoured method of paying for music is pay-for-performance. This could be like a penny-an-hour radio station, but this ignores portable MP3 players and large hard drives. Last time I checked, I can't connect anywhere while I'm riding the subway.

The next step in the thought process is to let you store the music, but whenever possible, the player notifies ... well, it notifies someone of this selection. Ah, yeah, right. I don't want to think at all about the privacy aspects of that model. [see RealAudio]

The final ah-ha is realizing that I don't need to charge for all performances, or even most performances. I just need a good-enough sample of how often the music is selected. This, it turns out is easy.

First, you embed additional information in MP3 files - you can do this today without breaking existing MP3 players. [see MP3,ID3v2] We can squeeze in about 64K for the equivalent of about 4 seconds of audio - in other words, it's really inexpensive. In this 64K, you get about 3 or 4 sets of information. Each set is for one entity - the artist, the label, and (critically) one or more for sponsors. Each set has (a) a big banner advert, (b) a tiny banner advert, (c) a 16x32 black and white logo, (d) a name (ascii), and (e) a special URL.

Now, crank up that compiler, and go back to your open source MP3 player. When you encounter this block of data, display the appropriate chunk from the section. Try for the big banner, or just use the small one. Portable players with a graphic screen can go for the 16x32, and the really simple portable players will go with scrolling the name. Then cycle through each set, moving forward about once every 20 seconds. Finally - if someone selects the banner, logo, or name (by clicking - or whatever) then launch that special URL. Notice that the selection is clearly a user action - nothing happens unless the listener does something.

The URL is very special. It uniquely identifies the advert, and also uniquely identifies the tune. It could uniquely identify the original download as well, but that's up to the distributor. Before launch, the player will add the X and Y address of the click on a banner, and a hash code (with salt) of the following few seconds of music.

The server that receives the URL will redirect the user to something appropriate - artist, label, or sponsor - to what was clicked. If it is a sponsor, it records the click-through. But as it does the redirect, it notes the tune that it came from. That's all for the core technical stuff. The server itself would sensibly be the label's, but there's no concrete requirement for that.

Now look at the information stream you're getting. The number of click-throughs is going to depend on both how widely the file is distributed and how often it is listened to. These are the core attributes we want to measure for music popularity. In addition, since sponsors get a click-through, the artist and label can share a click-through revenue stream and an impression stream. As a final note, if you let the URL identify the specific download, then you can get loyalty points for downloading and distributing tunes to your friends.

So, did we achieve what we were after? I think so (but then, I'm biased). We have:

• a benefit from hyper-distribution (or "Napster is our friend")
• measures of performance, not just distribution
• revenue sources for the artists and labels

Conveniently, this is completely compatible with streaming MP3, so netradio works immediately and automatically generates the artists revenue stream. I don't think there will be a lot of pressure from artists and labels to penalize (or even regulate) netradio if it is going to automatically generate income.

Yes, you could strip out the information and pass on the file. But this has relatively little effect. With legitimate hyper-distribution it becomes very difficult for a pirate to get their works out to a lot of people.

Most conveniently, this is completely backward compatible with MP3. Artists could start adding sponsor info to downloaded MP3 tomorrow, and it won't affect properly built players. Once a large enough base of tunes exists, players can be reasonably expected to support the option. As a final nice touch, this can even move into the physical world, by including pre-encoded MP3s on the end of each CD, ready to move to the PC, stereo, or portable player.

So - final question. Would this model help solve some of the difficulties we're having here?