From fiji at ayup.limey.net Tue Mar 6 08:09:11 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 6 Mar 2007 11:09:11 -0500 Subject: [ID3 Dev] Clarifying the TCON Frame In-Reply-To: <20070306134223.97355.qmail@web53506.mail.yahoo.com> References: <20070306134223.97355.qmail@web53506.mail.yahoo.com> Message-ID: <20070306160911.GA19922@ayup.limey.net> On Tue, Mar 06, 2007 at 05:42:23AM -0800, John Slane wrote: ... > The various music-management software I am using (MediaMonkey, > Mp3tag, etc.) are writing alphanumeric (English words) data to this > type (Genre) frame. So I would like to clarify a few things. > > (1) Is a TCON frame really supposed to contain a numeric string? If > so, what is the definition of a "numeric string"? The 2.3 version of TCON is a mess. 2.4 made some changes, but it is still a bit tricky. It should not contain just a numeric string. The format is optional parenthesized genre reference e.g.: (4) Then an optional textual refinement e.g.: Eurodisco There can be multiple references in the frame, and there are rules for escaping (s. There is no mention of multiple refinements, I would assume only one, and at the end of the string. You can also make references to RX for remix and CR for cover. So these are legal strings: (4) (4)Euro Disco Euro Disco (21)(4)(RX)Euro Disco > (2) If I have English words in a TCON frame > e.g. TCON = Soul R&B Motown > will that cause a problem with any apps down the road? I think that is the safest and sanest thing to do. I would not use the references stuff. iTunes puts just bare text in the frame and does not handle lists. And since iTunes is widely used, I would assume other software tries to read their tags. > (3) If alphanumeric words are allowed, what is the best way to > delimit multiple values in the frame? Are there any characters - > delimiters or otherwise - that should be avoided in a TCON frame? I do not think you can... the frame can not be repeated, and there is no identification of a list separator in that frame. The only possible thing would be to do: (4)Euro Disco(32)Duck Themed But I bet that is not well supported. However, you can indicate multiple genres through textual convention: Euro Disco; Duck Theme Euro Disco -- Duck Theme Euro Disco / Duck Theme Just pick what you think is most visually correct. 2.4 has proviisions for multiple values (using NUL as a separator). But I think most software just shows the first value and ignores the rest. > So far, I have experimented with simply adding the multiple genres > as a text string delimited only with spaces (as in the earlier > example). This seems to work OK for now, since I typically am > searching for files with TCON containing a certain substring. Is > this a robust use of the TCON frame? Are there rules/guidelines for > entering multiple values into a Text Information Frame? Discussed above. > One other question (which will show off what a newbie I am): > > What is the essential difference(s) between Text Information Frames > (TALB, TBPM, ...) and Comments Frames. As best I can tell, a Text > Information Frame is to contain a single string of text, with no > carriage returns allowed. A Comments Frame can contain carriage > returns (newlines). Is that the essential difference? Not quite... the T*** frames indeed can only contain a single text string with no newlines, but COMM is more general than that. It is basically a way for people (or programs) to stick arbittrary data into the tag. iTunes uses COMM for their audio normalization flag among other things. I would not expect COMMs to show up in various programs consistently... But yes, the "actual text" field can contain newlines. > Also, is the USLT (Lyrics) frame type basically the same as a COMM > frame, but simply with a specific purpose? Yes. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jwhite at cdtag.com Fri Mar 23 12:17:13 2007 From: jwhite at cdtag.com (Jud White) Date: Fri, 23 Mar 2007 14:17:13 -0500 Subject: [ID3 Dev] Compressed ID3 frames!? In-Reply-To: <20070323190850.GA32024@ayup.limey.net> References: <900931.3737.qm@web27011.mail.ukl.yahoo.com> <20070323190850.GA32024@ayup.limey.net> Message-ID: <460427B9.10406@cdtag.com> Same here. Ben Bennett wrote: > I support readiing and writing it in the perl id3 parser I wrote, but > I would not write compressed stuff out if I expected it to be > portable. So, compression is off by default in my lib. > > -ben > > On Fri, Mar 23, 2007 at 06:43:02PM +0000, Mathias Kunter wrote: > >> Does actually nobody care about this..? >> >> Regards >> Mathias >> >> >> >> ----- Urspr?ngliche Mail ---- >> Von: Mathias Kunter >> An: id3v2 at id3.org >> Gesendet: Donnerstag, den 22. M?rz 2007, 11:06:23 Uhr >> Betreff: [ID3 Dev] Compressed ID3 frames!? >> >> Hi there, >> >> I've got a question. ID3 version 2.3 and 2.4 define the ability to compress >> single frames with zlib. I've NEVER seen anybody who actually does this. >> My question now: do you know of any software which writes compressed >> ID3 frames?? >> >> Did you implement support for compressed frames in your tagging libraries, >> or is it useless to support this feature because nobody cares about >> compressed frames anyway? >> >> >> Thanks. >> Mathias >> >> >> >> >> >> >> ___________________________________________________________ >> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org >> For additional commands, e-mail: id3v2-help at id3.org >> >> >> >> >> >> >> >> ___________________________________________________________ >> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org >> For additional commands, e-mail: id3v2-help at id3.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jaslane64 at yahoo.com Sun Mar 4 09:00:42 2007 From: jaslane64 at yahoo.com (John Slane) Date: Sun, 4 Mar 2007 09:00:42 -0800 (PST) Subject: [ID3 Dev] User-Defined Frames In-Reply-To: <45EA324B.902@cdtag.com> Message-ID: <790408.98324.qm@web53504.mail.yahoo.com> Thanks very much for your kind reply. Your perspective is very helpful to me, since my experience in this area is very limited. Your suggestions will hopefully help me avoid making poor judgments that will come back to bite me later. I know it was a long list of questions, and I appreciate your patience in addressing them all. I am very grateful. Jud White wrote: 1. Yes, text in TCON is compliant. It's not defined as only a numeric string. 2. The preferred way to delimit genres is with a null terminator, although only a few apps/libs support this. There's no reason spaces should break another reader. 3. TIT1 might be good for "Theme", if your software writes this frame. The definition for TIT1: "The 'Content group description' frame is used if the sound belongs to a larger category of sounds/music. For example, classical music is often sorted in different musical sections (e.g. "Piano Concerto", "Weather - Hurricane").". If not, TXXX seems most appropriate, but you mentioned MM doesn't support these either. Foobar definitely allows TXXX. I would stay away from using COMM, because it's not a comment, although iTunes and other software abuse this frame liberally. 4. It doesn't break the spec that MM writes its own COMM identifiers, but it is messy IMO. I wouldn't worry about it breaking another app, but I would doubt another app would treat a MM COMM frame as anything other than a comment. 5. TXXX is appropriate if you want to define your own metadata. A populer one is "Album Artist" for compilation CD's. So you could have TXXX/Album Artist/DJ Dara, for example. COMM is meant for comments, maybe some notes about a live recording, or a press release about a CD, etc. If you use proprietary descriptors in COMM then you're righ to worry about lock-in. You may be able to find someone willing to write a conversion utility to take COMM/MediaMonkey frames and translate them into whatever you're looking for in the future. John Slane wrote: > As you will be able to infer, I am pretty much a newbie to mp3 and > ID3. I am about to begin tagging a few thousand mp3 files, and I sure > would like to get it right the first time. I've read through the > ID3v2.3 standard and I have experimented with modifying tags using > mp3Tag and MediaMonkey. I look at how each program modified the tag > by reading the tag with id3.exe. While I believe I understand the > basics now, I have a couple of nagging questions that remain, and I > hope that you can kindly help me out. > > I want to use tag metadata to build "AutoPlaylists" in MediaMonkey. > Basically, I'd like to be able to tell my jukebox - for example - to > play songs from 1968 that have the Genre = Soul or Funk AND the Theme > = Cars or Dancing. This idea raises a few issues: > > (1) A TCON (genre) frame in ID3v2.3 is defined as a numeric string. I > notice, though, that both MediaMonkey and mp3Tag write alphabetic > words into this frame (as confirmed by id3.exe). Is this in > conformity with the spec, and might it cause any problem with reading > the tag in other programs? > > (2) Although only one TCON frame is allowed per tag, I was able to > write multiple genre values into the TCON frame, simply by writing > them as a string, delimiting them with spaces or other characters. > MediaMonkey is able to then search on any portion of the string to > make a playlist. Is there any potential problem (with any tag-reading > software) that arises from putting multiple genre values into the > single TCON frame? > > (3) Now I come to my "Theme" field. Since there is no declare Theme > frame type in ID3 and no Theme field in MediaMonkey, I could sneak > "Theme" values into one of MediaMonkey's predefined fields that I do > not use; but it would, of course, be mislabeled. On the other hand, I > could put my "Theme" values into a TXXX or a COMM frame. MediaMonkey > does not create or recognize any TXXX frames, but it does offer a few > user-defined COMM fields (Custom1 - Custom3). So I could use one of > these, and use the Descriptor "Theme," and enter my multiple-valued > theme data in as a string, with whatever delimiters seem appropriate. > Does that make sense? Are there any kind of rules for choosing > delimiters, in terms of compatibility with the world of software out > there? > > (4) When I do use one of MediaMonkey's "user-defined" COMM fields, I > note that MediaMonkey imposes its own descriptor on the tag frame. > For example, if I enter "January" into user-defined field "Custom 1", > I get the following tag frame: > COMM = Songs-DB_Custom1 January. > So MediaMonkey has predefined descriptors that it uses for its > "user-defined" fields/frames. These fields seem to work just fine > within MediaMonkey, for making playlists, etc. But will they cause > problems for me in the future if I migrate my music collection to > another jukebox software or some other software application? I fear > that using the MediaMonkey jargon in the tag will cause me recognition > problems elsewhere. > > (5) Considering Issues (2) and (3) together, I wonder about the > difference between a text frame and a comment frame. For example, how > are a TXXX and a COMM actually different (so I know which to choose > for what). Each one can have multiple occurrences in the same tag; > each one takes a descriptor to distinguish it from its kin in the same > tag; and each one accepts a text string as its actual data. So how > are they different? Does one allow a LONGER string, or broader > formatting, or what? I'd like to know when a TXXX is appropriate, and > when a COMM is appropriate. > > As you can see, I'm trying to figure out how to cram non-standard > information (multiple genres, music themes, months of the year) into > my ID3v2.3 tags. And my current jukebox (MediaMonkey) apparently > gives my a couple of options for doing this, but they seem rather > limited, and I worry that using them will tie me to this application > for the rest of my life (unless I want to retag thousands of files). > Any general advice you can offer on making universally acceptable tags > that contain non-standard metadata will be greatly appreciated. > > Thanks for your patience in reading all this, and for any advice you > might have on any or all of these issues. I feel a bit overwhelmed at > the moment, and reluctant to begin tagging my collection until I get a > bit more comfortable. > > jaslane64 > Dublin Ohio > > ------------------------------------------------------------------------ > TV dinner still cooling? > Check out "Tonight's Picks" > on Yahoo! TV. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsorensen at gmail.com Fri Mar 16 06:38:59 2007 From: tsorensen at gmail.com (Tom Sorensen) Date: Fri, 16 Mar 2007 09:38:59 -0400 Subject: [ID3 Dev] Using multiple tags to specify genre and other traits. In-Reply-To: <45FA9C87.8010206@usit.uio.no> References: <45FA9C87.8010206@usit.uio.no> Message-ID: <4da424620703160638i177317d6l8278f0a582fc5ea6@mail.gmail.com> You're already allowed to have multiple genres in the TCON field. v2.4 is explicit about how to separate them (with a NULL), but the more predominant v2.3 is not (some use NULLs, some use spaces). There's no need to allow for multiple TCON fields. One issue is that many taggers don't explicitly allow you to specify more than one genre though, especially the v2.3 taggers. Which is why space delimitation is more common in v2.3 -- just string together the genres with spaces and you're done. There's a minor complication that you cannot immediately distinguish "acid jazz" from "acid funk jazz", but that's largely avoidable -- when you're doing genre searches, enclose the multiple-word genre in quotes and your software _should_ do the right thing. Tom On 3/16/07, St?le Asker?d Johansen wrote: > > Hi. I'm new. > > This may be an old discussion, but important nonetheless. > > Historically, the "genre" has been the standard for specifying > the "type" of music in an mp3-file. However, a piece of music will often > belong to more than one genre. Moreover, people have not always agreed > on which genres are needed to describe their music, so this has led > to a plethora of more or less strange genres in use. > > It is time to move on. > > Structuring information is difficult. As a sysadmin trying to manage > lots of different hosts with different roles, I meet this problem on a > near daily basis. The solution is using multiple "roles", or "tags" to > describe various "abilities" of something, whether it is webpages, > music or servers. > > Over the last couple of years, using multiple "tags" has become a de > facto standard in some internet communitites for structuring and > categorizing webpages. A look at del.icio.us is a good example. This > allows for much more fine-tuned selection criteria than just using a > single variable. > > Let me give you an example. > > It's friday. I'm tired from a long week. I want to play some suitable > music. Instead of choosing the genre "slow jazz", I want to choose > > jazz AND slow AND 70s AND instrumental AND NOT french AND NOT sad > > Tomorrow I'm having some guests over. For dinner we'd like some > music. In want to choose > > (jazz OR classical) AND piano AND (norwegian OR swedish) AND NOT modern > > So. What do you think? My guess is that this won't be very difficult to > code, the problem is to agree on a standard for this. Or is it a stupid, > childish idea? > > > -- > St?le Johansen, Norway. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jaslane64 at yahoo.com Tue Mar 6 08:55:44 2007 From: jaslane64 at yahoo.com (John Slane) Date: Tue, 6 Mar 2007 08:55:44 -0800 (PST) Subject: [ID3 Dev] Clarifying the TCON Frame In-Reply-To: <20070306160911.GA19922@ayup.limey.net> Message-ID: <20070306165544.92702.qmail@web53508.mail.yahoo.com> Thanks very much for your patient and thorough answers. You have cleared up most of the confusion I had, and I feel ready to design a way to fit my metadata into ID3v2.3 tags that will be handled by a majority of apps. I must say, this task was more complex than I expected, given the nonuniform way that the ID3 tags are exploited by various apps. Without your help, I would have little confidence in proceeding. Thanks, again, for taking the time to help me out. Ben Bennett wrote: On Tue, Mar 06, 2007 at 05:42:23AM -0800, John Slane wrote: ... > The various music-management software I am using (MediaMonkey, > Mp3tag, etc.) are writing alphanumeric (English words) data to this > type (Genre) frame. So I would like to clarify a few things. > > (1) Is a TCON frame really supposed to contain a numeric string? If > so, what is the definition of a "numeric string"? The 2.3 version of TCON is a mess. 2.4 made some changes, but it is still a bit tricky. It should not contain just a numeric string. The format is optional parenthesized genre reference e.g.: (4) Then an optional textual refinement e.g.: Eurodisco There can be multiple references in the frame, and there are rules for escaping (s. There is no mention of multiple refinements, I would assume only one, and at the end of the string. You can also make references to RX for remix and CR for cover. So these are legal strings: (4) (4)Euro Disco Euro Disco (21)(4)(RX)Euro Disco > (2) If I have English words in a TCON frame > e.g. TCON = Soul R&B Motown > will that cause a problem with any apps down the road? I think that is the safest and sanest thing to do. I would not use the references stuff. iTunes puts just bare text in the frame and does not handle lists. And since iTunes is widely used, I would assume other software tries to read their tags. > (3) If alphanumeric words are allowed, what is the best way to > delimit multiple values in the frame? Are there any characters - > delimiters or otherwise - that should be avoided in a TCON frame? I do not think you can... the frame can not be repeated, and there is no identification of a list separator in that frame. The only possible thing would be to do: (4)Euro Disco(32)Duck Themed But I bet that is not well supported. However, you can indicate multiple genres through textual convention: Euro Disco; Duck Theme Euro Disco -- Duck Theme Euro Disco / Duck Theme Just pick what you think is most visually correct. 2.4 has proviisions for multiple values (using NUL as a separator). But I think most software just shows the first value and ignores the rest. > So far, I have experimented with simply adding the multiple genres > as a text string delimited only with spaces (as in the earlier > example). This seems to work OK for now, since I typically am > searching for files with TCON containing a certain substring. Is > this a robust use of the TCON frame? Are there rules/guidelines for > entering multiple values into a Text Information Frame? Discussed above. > One other question (which will show off what a newbie I am): > > What is the essential difference(s) between Text Information Frames > (TALB, TBPM, ...) and Comments Frames. As best I can tell, a Text > Information Frame is to contain a single string of text, with no > carriage returns allowed. A Comments Frame can contain carriage > returns (newlines). Is that the essential difference? Not quite... the T*** frames indeed can only contain a single text string with no newlines, but COMM is more general than that. It is basically a way for people (or programs) to stick arbittrary data into the tag. iTunes uses COMM for their audio normalization flag among other things. I would not expect COMMs to show up in various programs consistently... But yes, the "actual text" field can contain newlines. > Also, is the USLT (Lyrics) frame type basically the same as a COMM > frame, but simply with a specific purpose? Yes. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------- Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wheeler at kde.org Mon Mar 26 04:21:53 2007 From: wheeler at kde.org (Scott Wheeler) Date: Mon, 26 Mar 2007 13:21:53 +0200 Subject: [ID3 Dev] Compressed ID3 frames!? In-Reply-To: <213010.26334.qm@web27012.mail.ukl.yahoo.com> References: <213010.26334.qm@web27012.mail.ukl.yahoo.com> Message-ID: <4607ACD1.1040808@kde.org> Mathias Kunter wrote: > Did you implement support for compressed frames in your tagging libraries [...] TagLib supports reading them, not writing them (since I think compressed frames are silly). I've only run across them in the wild maybe once or twice and I don't know of anything that writes them, but obviously something does. -Scott --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jwhite at cdtag.com Wed Mar 28 00:48:29 2007 From: jwhite at cdtag.com (Jud White) Date: Wed, 28 Mar 2007 02:48:29 -0500 Subject: [ID3 Dev] Suggestion for 2.4.1 Update In-Reply-To: <4609EE7C.6030900@cox.net> References: <4609EE7C.6030900@cox.net> Message-ID: <460A1DCD.4070607@cdtag.com> I think TPE1 is appropriate for track artist. It would be non-intuitive from my POV to search for an artist and have to consider two fields because one track happens to reside on a VA album. TXXX/Album Artist is used by foobar and other players/taggers to denote the album artist in a VA album. I think a formal field for Album Artist would make a great addendum. As shown with CHAP, CTOC and ATXT a revision number isn't needed (many reasons for that as well). Dennis W. Mattison wrote: > I suggest another field be added to the ID3V2 spec specifically for > Track Artists (for use as a holder for "featured artist" or for the > artist responsible for a track in a "Various Artists" compilation > CD.) I propose a field similar to the TPE1 field. Attached is the > verbage for a new TRAR field (if accepted) to be included in the 4.2.2 > section of the spec: > > TRAR > The 'Featured Artist/Track Artist' frame is intended for a featured > artist of a song, or in the case of a "Various Artists" compilation, > is intended for the Lead Artist/Lead Performer/Soloist of the track. > > There have been several implementations of a "Track Artist" field in > MP3 ID3 tags, such as MusicMatch's COMM engMusicMatch_TrackArtist > field, and nobody seems to want to standardize on one particular field > name which everyone can commonly use. I have a lot of Various Artist > compilations, which I'd love to keep the Artist as "Various Artist" in > order to group them together, but also indicate the artist of the > particular track I am listening to. Adding a TRAR field to the spec > would allow everyone to standardize their players to allow for this > level of capability. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dwmattisoncv at cox.net Wed Mar 28 07:20:34 2007 From: dwmattisoncv at cox.net (Dennis W. Mattison) Date: Wed, 28 Mar 2007 07:20:34 -0700 Subject: [ID3 Dev] Suggestion for 2.4.1 Update In-Reply-To: <460A1DCD.4070607@cdtag.com> References: <4609EE7C.6030900@cox.net> <460A1DCD.4070607@cdtag.com> Message-ID: <460A79B2.2090003@cox.net> Jud White wrote: > I think TPE1 is appropriate for track artist. It would be > non-intuitive from my POV to search for an artist and have to consider > two fields because one track happens to reside on a VA album. > > TXXX/Album Artist is used by foobar and other players/taggers to > denote the album artist in a VA album. I think a formal field for > Album Artist would make a great addendum. As shown with CHAP, CTOC > and ATXT a revision number isn't needed (many reasons for that as well). > I am a collector (of CDs, not a sharer of mp3s) and not a developer of mp3 software, and my collection has a number of Various Artists albums (which allows me to collect a bunch of good music instead of one good song out of a bad album.) I will try TXXX/Album Artist, but what I am looking for is a standard way of doing this across all players and not just a kludge. Obviously, as mentioned by others, the spec would probably take forever to implement across all of the players, but it would be nice, whether we standardize TXXX/Album Artist or standardize a new Track Artist field, to have something in addition to TPE1 (which works fine for track artist) to specify that the album is a Various Artist album (for grouping the album together in a collection.) Obviously TPE1/TPE2 or TMCL/TIPL could be used for feature artist. But TPE1/TPE2 appears to have alternate uses which might conflict with the VA Album use and TMCL/TIPL is not well supported by the players I've used. Still, it was just a suggestion, and I would not in any way be put off if it was decided that a TRAR field was unnecessary. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From s.a.johansen at usit.uio.no Wed Mar 28 05:08:43 2007 From: s.a.johansen at usit.uio.no (=?ISO-8859-1?Q?St=E5le_Asker=F8d_Johansen?=) Date: Wed, 28 Mar 2007 14:08:43 +0200 Subject: [ID3 Dev] Suggestion for 2.4.1 - TAGS In-Reply-To: <460A588F.40006@kde.org> References: <570318.50180.qm@web27006.mail.ukl.yahoo.com> <45FE7BD2.3070302@usit.uio.no> <20070319140233.GA2249@ayup.limey.net> <460A4C35.4070806@usit.uio.no> <460A588F.40006@kde.org> Message-ID: <460A5ACB.4030703@usit.uio.no> Scott Wheeler wrote: > St?le Asker?d Johansen wrote: >> I'd hereby like to suggest another field be added to the ID3V2 spec [...] > > It's taken more than half a decade to have 2.4.0 reasonably well > supported. I wouldn't count on folks jumping on board for a new > version. The only thing that's been seriously considered is a revision > of the spec to clear up some ambiguities and even at that, I don't think > there's anyone doing concrete work on such. > Ah. I see. :-) If we don't mind the versioning, what is the best way to get this change implemented? -- St?le. Not a programmer. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Sat Mar 17 10:36:32 2007 From: wheeler at kde.org (Scott Wheeler) Date: Sat, 17 Mar 2007 18:36:32 +0100 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <20070317162556.GA1663@ayup.limey.net> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> Message-ID: <45FC2720.2050201@kde.org> Ben Bennett wrote: > The 2.4 implementations I've seen do not handle multiple substrings > (amarok, itunes). > TagLib, used by Amarok does, but the Amarok GUI (and in fact the "simple" TagLib API) does not. They just take the first value. >> So, if you write a 0 terminator at the end of the string, you >> definitely are on the safe side. >> > > For 2.3 that is certainly true, but I am not so sure in the case of > 2.4. If you have a terminator following the value then doesn't that > imply a 0-length item? > Yes, I've mentioned that in the past. It's a subtle distinction, but in 2.4 a null terminated string technically indicates two strings, the second one being empty. -Scott --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Wed Mar 28 10:41:44 2007 From: wheeler at kde.org (Scott Wheeler) Date: Wed, 28 Mar 2007 19:41:44 +0200 Subject: [ID3 Dev] Suggestion for 2.4.1 - TAGS In-Reply-To: <460A5ACB.4030703@usit.uio.no> References: <570318.50180.qm@web27006.mail.ukl.yahoo.com> <45FE7BD2.3070302@usit.uio.no> <20070319140233.GA2249@ayup.limey.net> <460A4C35.4070806@usit.uio.no> <460A588F.40006@kde.org> <460A5ACB.4030703@usit.uio.no> Message-ID: <460AA8D8.4050404@kde.org> St?le Asker?d Johansen wrote: > Ah. I see. :-) > > If we don't mind the versioning, what is the best way to get this > change implemented? Well, the problem is that changed in the spec is different from changed in the real world. To get it changed in the spec, there would need to be someone organizing the process or releasing an update, a general consensus on this list, a draft, and then a new standard. And that's the easy part. Then you have to get the people with various implementations to update their projects. The time, for instance, between the release of the 2.4.0 standard and Apple and Microsoft supporting them was about 5 years. The first projects to switch over probably showed up 1-2 years after the standard update. Then GUIs have to be updated to support new schemes. Most GUIs just ignore most frame types. I'm personally strongly opposed to any additional changes to the ID3v2 format (though not opposed to a clarified standard draft); previous changes have only complicated adoption and I expect that additional significant revisions would create more problems than they would solve; previous updates certainly have. -Scott --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From s.a.johansen at usit.uio.no Wed Mar 28 04:06:29 2007 From: s.a.johansen at usit.uio.no (=?ISO-8859-1?Q?St=E5le_Asker=F8d_Johansen?=) Date: Wed, 28 Mar 2007 13:06:29 +0200 Subject: [ID3 Dev] Suggestion for 2.4.1 - TAGS In-Reply-To: <20070319140233.GA2249@ayup.limey.net> References: <570318.50180.qm@web27006.mail.ukl.yahoo.com> <45FE7BD2.3070302@usit.uio.no> <20070319140233.GA2249@ayup.limey.net> Message-ID: <460A4C35.4070806@usit.uio.no> Ben Bennett wrote: >> >> [TAGS]: rock, folk, instrumental, oldie, sorrowful, slow, piano, violin, >> swedish, scandinavian, progressive, 70s, 1971, soundtrack > > Who is the target audience? And what tools are you going to use? > The target audience is people with very large collections of music. Tools do not exist yet. Any developers of players or taggers here? > >> A very good point, and I realize that this information often will have >> to be entered and used by each user based on personal taste. An >> alternative is to make something wiki-like where people can collaborate >> on making a common framework, like for instance del.icio.us. > > That would be useful. Have you seen musicbrainz.org? They are sort > of edging in the direction of having an internet-wide editable music > DB... They don't yet have arbitrary tagging. > This site is a good start, at least. I'd hereby like to suggest another field be added to the ID3V2 spec specifically for atbitrary tags. TAGS The "Tags" frame is intended for storing multiple strings to describe the "roles" a song may have. These roles may include both numerous genres as well as for example mood or instruments or other characteristics. In this sense, the frame will overlap with other frames. This is by design, to make intelligent searches easier with the proper implmented tools. -- St?le --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jaslane64 at yahoo.com Sat Mar 3 14:03:17 2007 From: jaslane64 at yahoo.com (John Slane) Date: Sat, 3 Mar 2007 14:03:17 -0800 (PST) Subject: [ID3 Dev] User-Defined Frames Message-ID: <283328.6459.qm@web53514.mail.yahoo.com> As you will be able to infer, I am pretty much a newbie to mp3 and ID3. I am about to begin tagging a few thousand mp3 files, and I sure would like to get it right the first time. I've read through the ID3v2.3 standard and I have experimented with modifying tags using mp3Tag and MediaMonkey. I look at how each program modified the tag by reading the tag with id3.exe. While I believe I understand the basics now, I have a couple of nagging questions that remain, and I hope that you can kindly help me out. I want to use tag metadata to build "AutoPlaylists" in MediaMonkey. Basically, I'd like to be able to tell my jukebox - for example - to play songs from 1968 that have the Genre = Soul or Funk AND the Theme = Cars or Dancing. This idea raises a few issues: (1) A TCON (genre) frame in ID3v2.3 is defined as a numeric string. I notice, though, that both MediaMonkey and mp3Tag write alphabetic words into this frame (as confirmed by id3.exe). Is this in conformity with the spec, and might it cause any problem with reading the tag in other programs? (2) Although only one TCON frame is allowed per tag, I was able to write multiple genre values into the TCON frame, simply by writing them as a string, delimiting them with spaces or other characters. MediaMonkey is able to then search on any portion of the string to make a playlist. Is there any potential problem (with any tag-reading software) that arises from putting multiple genre values into the single TCON frame? (3) Now I come to my "Theme" field. Since there is no declare Theme frame type in ID3 and no Theme field in MediaMonkey, I could sneak "Theme" values into one of MediaMonkey's predefined fields that I do not use; but it would, of course, be mislabeled. On the other hand, I could put my "Theme" values into a TXXX or a COMM frame. MediaMonkey does not create or recognize any TXXX frames, but it does offer a few user-defined COMM fields (Custom1 - Custom3). So I could use one of these, and use the Descriptor "Theme," and enter my multiple-valued theme data in as a string, with whatever delimiters seem appropriate. Does that make sense? Are there any kind of rules for choosing delimiters, in terms of compatibility with the world of software out there? (4) When I do use one of MediaMonkey's "user-defined" COMM fields, I note that MediaMonkey imposes its own descriptor on the tag frame. For example, if I enter "January" into user-defined field "Custom 1", I get the following tag frame: COMM = Songs-DB_Custom1 January. So MediaMonkey has predefined descriptors that it uses for its "user-defined" fields/frames. These fields seem to work just fine within MediaMonkey, for making playlists, etc. But will they cause problems for me in the future if I migrate my music collection to another jukebox software or some other software application? I fear that using the MediaMonkey jargon in the tag will cause me recognition problems elsewhere. (5) Considering Issues (2) and (3) together, I wonder about the difference between a text frame and a comment frame. For example, how are a TXXX and a COMM actually different (so I know which to choose for what). Each one can have multiple occurrences in the same tag; each one takes a descriptor to distinguish it from its kin in the same tag; and each one accepts a text string as its actual data. So how are they different? Does one allow a LONGER string, or broader formatting, or what? I'd like to know when a TXXX is appropriate, and when a COMM is appropriate. As you can see, I'm trying to figure out how to cram non-standard information (multiple genres, music themes, months of the year) into my ID3v2.3 tags. And my current jukebox (MediaMonkey) apparently gives my a couple of options for doing this, but they seem rather limited, and I worry that using them will tie me to this application for the rest of my life (unless I want to retag thousands of files). Any general advice you can offer on making universally acceptable tags that contain non-standard metadata will be greatly appreciated. Thanks for your patience in reading all this, and for any advice you might have on any or all of these issues. I feel a bit overwhelmed at the moment, and reluctant to begin tagging my collection until I get a bit more comfortable. jaslane64 Dublin Ohio --------------------------------- TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smitht at cs.uchicago.edu Tue Mar 20 19:10:00 2007 From: smitht at cs.uchicago.edu (Trevor Summers Smith) Date: Tue, 20 Mar 2007 21:10:00 -0500 (CDT) Subject: [ID3 Dev] Test Suite Message-ID: Hello, I'm working on a library to read and write ID3v2 tags, and am wondering if anyone is aware of a comprehensive, or even sizable, testing suite. I've looked around and found some examples in the libraries listed on the id3.org website, but nothing very large. If such a thing has not yet been done, I'd be interested in gathering examples and putting such a thing together, as I think it would be a valuable tool for the developer community. Thanks, Trevor Smith --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Mon Mar 19 07:02:33 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Mon, 19 Mar 2007 10:02:33 -0400 Subject: [ID3 Dev] Using multiple tags to specify genre and other traits. In-Reply-To: <45FE7BD2.3070302@usit.uio.no> References: <570318.50180.qm@web27006.mail.ukl.yahoo.com> <45FE7BD2.3070302@usit.uio.no> Message-ID: <20070319140233.GA2249@ayup.limey.net> On Mon, Mar 19, 2007 at 01:02:26PM +0100, St?le Asker?d Johansen wrote: > [TLAN]: norwegian, british, hawaiian, french > [TYER]: 1980, 1965, 2003, 1999 > [TMOO]: sad, happy, bouncy, slow, fast, joyful > [TCON]: rock, pop, balkan-brass, classical, noseflute > > But this: > > [TAGS]: rock, folk, instrumental, oldie, sorrowful, slow, piano, violin, > swedish, scandinavian, progressive, 70s, 1971, soundtrack Who is the target audience? And what tools are you going to use? > A very good point, and I realize that this information often will have > to be entered and used by each user based on personal taste. An > alternative is to make something wiki-like where people can collaborate > on making a common framework, like for instance del.icio.us. That would be useful. Have you seen musicbrainz.org? They are sort of edging in the direction of having an internet-wide editable music DB... They don't yet have arbitrary tagging. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jaslane64 at yahoo.com Tue Mar 6 05:42:23 2007 From: jaslane64 at yahoo.com (John Slane) Date: Tue, 6 Mar 2007 05:42:23 -0800 (PST) Subject: [ID3 Dev] Clarifying the TCON Frame Message-ID: <20070306134223.97355.qmail@web53506.mail.yahoo.com> The ID3v2.3 spec as written on the ID3.org website says: "TCON "The 'Content type', which previously was stored as a one byte numeric value only, is now a numeric string. You may use one or several of the types as ID3v1.1 did or ..... define your own." The various music-management software I am using (MediaMonkey, Mp3tag, etc.) are writing alphanumeric (English words) data to this type (Genre) frame. So I would like to clarify a few things. (1) Is a TCON frame really supposed to contain a numeric string? If so, what is the definition of a "numeric string"? (2) If I have English words in a TCON frame e.g. TCON = Soul R&B Motown will that cause a problem with any apps down the road? (3) If alphanumeric words are allowed, what is the best way to delimit multiple values in the frame? Are there any characters - delimiters or otherwise - that should be avoided in a TCON frame? So far, I have experimented with simply adding the multiple genres as a text string delimited only with spaces (as in the earlier example). This seems to work OK for now, since I typically am searching for files with TCON containing a certain substring. Is this a robust use of the TCON frame? Are there rules/guidelines for entering multiple values into a Text Information Frame? One other question (which will show off what a newbie I am): What is the essential difference(s) between Text Information Frames (TALB, TBPM, ...) and Comments Frames. As best I can tell, a Text Information Frame is to contain a single string of text, with no carriage returns allowed. A Comments Frame can contain carriage returns (newlines). Is that the essential difference? Also, is the USLT (Lyrics) frame type basically the same as a COMM frame, but simply with a specific purpose? Thanks for any advice/guidance you can offer. --------------------------------- Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwhite at cdtag.com Mon Mar 5 22:22:01 2007 From: jwhite at cdtag.com (Jud White) Date: Tue, 06 Mar 2007 00:22:01 -0600 Subject: [ID3 Dev] iTunes APIC - Unicode description bug fixed Message-ID: <45ED0889.7080902@cdtag.com> Good news.. The good people at Apple fixed an ID3v2 bug! In iTunes 7.1 you can now read picture frames written with a unicode description. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dalepres at msn.com Sat Mar 17 13:24:48 2007 From: dalepres at msn.com (Dale Preston) Date: Sat, 17 Mar 2007 15:24:48 -0500 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <45FC4A2C.3080906@mp3tag.de> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> <45FC2720.2050201@kde.org> <45FC4153.5070901@mp3tag.de> <45FC455A.2040405@fastmail.fm> <45FC4A2C.3080906@mp3tag.de> Message-ID: While you're at it, I have seen some tags from MP3Tag that do not include the three character language descriptor on comment tags. Has that been fixed in later versions? Dale -----Original Message----- From: Florian Heidenreich [mailto:support at mp3tag.de] Sent: Saturday, March 17, 2007 3:06 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 0-termination in text frames Paul Taylor wrote: > Florian Heidenreich wrote: >> I'm still not sure about the issue. The ID3v2.4 spec from >> http://id3.org/id3v2.4.0-structure presents a list of possible >> encodings at '4. ID3v2 frame overview' where the terminating 0 is >> explicitly included in every text string: >> >> >> Frames that allow different types of text encoding contains a text >> encoding description byte. Possible encodings: >> >> $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. >> $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All >> strings in the same frame SHALL have the same byteorder. >> Terminated with $00 00. >> $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. >> Terminated with $00 00. >> $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. >> >> >> According to that list it seems to me, that every string includes a >> terminating $00 (or $00 00 when using UTF-16). >> >> What do you think about it? >> >> Thank you! >> >> Kind regards, >> Florian >> >> > I think it is just saying that if you use a null terminated string then > you should terminate correctly for the encoding you use. > does not include a null terminator, > where a null terminator is required it is explicity stated in the spec > as these extracts show. [..] Thanks for the clarification! It seems that I'll have to change Mp3tag's ID3 writer :) Kind regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dwmattisoncv at cox.net Tue Mar 27 21:26:36 2007 From: dwmattisoncv at cox.net (Dennis W. Mattison) Date: Tue, 27 Mar 2007 21:26:36 -0700 Subject: [ID3 Dev] Suggestion for 2.4.1 Update Message-ID: <4609EE7C.6030900@cox.net> I suggest another field be added to the ID3V2 spec specifically for Track Artists (for use as a holder for "featured artist" or for the artist responsible for a track in a "Various Artists" compilation CD.) I propose a field similar to the TPE1 field. Attached is the verbage for a new TRAR field (if accepted) to be included in the 4.2.2 section of the spec: TRAR The 'Featured Artist/Track Artist' frame is intended for a featured artist of a song, or in the case of a "Various Artists" compilation, is intended for the Lead Artist/Lead Performer/Soloist of the track. There have been several implementations of a "Track Artist" field in MP3 ID3 tags, such as MusicMatch's COMM engMusicMatch_TrackArtist field, and nobody seems to want to standardize on one particular field name which everyone can commonly use. I have a lot of Various Artist compilations, which I'd love to keep the Artist as "Various Artist" in order to group them together, but also indicate the artist of the particular track I am listening to. Adding a TRAR field to the spec would allow everyone to standardize their players to allow for this level of capability. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From support at mp3tag.de Sat Mar 17 12:28:19 2007 From: support at mp3tag.de (Florian Heidenreich) Date: Sat, 17 Mar 2007 20:28:19 +0100 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <45FC2720.2050201@kde.org> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> <45FC2720.2050201@kde.org> Message-ID: <45FC4153.5070901@mp3tag.de> Hello, Scott Wheeler wrote: > Ben Bennett wrote: >> The 2.4 implementations I've seen do not handle multiple substrings >> (amarok, itunes). >> > > TagLib, used by Amarok does, but the Amarok GUI (and in fact the > "simple" TagLib API) does not. They just take the first value. Mp3tag also does :) >>> So, if you write a 0 terminator at the end of the string, you >>> definitely are on the safe side. >>> >> >> For 2.3 that is certainly true, but I am not so sure in the case of >> 2.4. If you have a terminator following the value then doesn't that >> imply a 0-length item? >> > > Yes, I've mentioned that in the past. It's a subtle distinction, but in > 2.4 a null terminated string technically indicates two strings, the > second one being empty. Thanks all for your comments! I'm still not sure about the issue. The ID3v2.4 spec from http://id3.org/id3v2.4.0-structure presents a list of possible encodings at '4. ID3v2 frame overview' where the terminating 0 is explicitly included in every text string: Frames that allow different types of text encoding contains a text encoding description byte. Possible encodings: $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All strings in the same frame SHALL have the same byteorder. Terminated with $00 00. $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. Terminated with $00 00. $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. According to that list it seems to me, that every string includes a terminating $00 (or $00 00 when using UTF-16). What do you think about it? Thank you! Kind regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jaslane64 at yahoo.com Wed Mar 7 04:21:31 2007 From: jaslane64 at yahoo.com (John Slane) Date: Wed, 7 Mar 2007 04:21:31 -0800 (PST) Subject: [ID3 Dev] Clarifying the TCON Frame In-Reply-To: <20070306205919.GA29340@ayup.limey.net> Message-ID: <823119.20558.qm@web53503.mail.yahoo.com> Hey, thanks for the ideas. After I make sure my initial setup works well within MediaMonkey and Mp3tag (the apps I'm using to create and manage my library), I should test out an initial sampling against iTunes, winamp, and amarok - so that I cover the popular apps and also prove I can migrate to a v2.4 environment. I really appreciate your suggestions. I can use all the help I can get. Gratefully, John Ben Bennett wrote: Yeah, it is a maze of twisty passages, all alike ;-) My rule of thumb is to try iTunes to see what they do (although their 2.4 implementation has some nasty bugs), and test that against winamp for 2.3 support and amarok (which uses a newer fancy id3 2.4 library). As long as you are willing to use a subset of the spec, and don't stray too far into the wilds, things will go well. -ben On Tue, Mar 06, 2007 at 08:55:44AM -0800, John Slane wrote: > Thanks very much for your patient and thorough answers. You have cleared up most of the confusion I had, and I feel ready to design a way to fit my metadata into ID3v2.3 tags that will be handled by a majority of apps. > > I must say, this task was more complex than I expected, given the nonuniform way that the ID3 tags are exploited by various apps. Without your help, I would have little confidence in proceeding. > > Thanks, again, for taking the time to help me out. > > Ben Bennett wrote: On Tue, Mar 06, 2007 at 05:42:23AM -0800, John Slane wrote: > ... > > The various music-management software I am using (MediaMonkey, > > Mp3tag, etc.) are writing alphanumeric (English words) data to this > > type (Genre) frame. So I would like to clarify a few things. > > > > (1) Is a TCON frame really supposed to contain a numeric string? If > > so, what is the definition of a "numeric string"? > > > The 2.3 version of TCON is a mess. 2.4 made some changes, but it is > still a bit tricky. > > It should not contain just a numeric string. > > The format is optional parenthesized genre reference e.g.: (4) > Then an optional textual refinement e.g.: Eurodisco > > There can be multiple references in the frame, and there are rules for > escaping (s. There is no mention of multiple refinements, I would > assume only one, and at the end of the string. > > You can also make references to RX for remix and CR for cover. > > So these are legal strings: > (4) > (4)Euro Disco > Euro Disco > (21)(4)(RX)Euro Disco > > > > (2) If I have English words in a TCON frame > > e.g. TCON = Soul R&B Motown > > will that cause a problem with any apps down the road? > > I think that is the safest and sanest thing to do. I would not use > the references stuff. iTunes puts just bare text in the frame and > does not handle lists. And since iTunes is widely used, I would > assume other software tries to read their tags. > > > > (3) If alphanumeric words are allowed, what is the best way to > > delimit multiple values in the frame? Are there any characters - > > delimiters or otherwise - that should be avoided in a TCON frame? > > I do not think you can... the frame can not be repeated, and there is > no identification of a list separator in that frame. The only > possible thing would be to do: > (4)Euro Disco(32)Duck Themed > > But I bet that is not well supported. > > However, you can indicate multiple genres through textual convention: > Euro Disco; Duck Theme > Euro Disco -- Duck Theme > Euro Disco / Duck Theme > > Just pick what you think is most visually correct. > > 2.4 has proviisions for multiple values (using NUL as a separator). > But I think most software just shows the first value and ignores the > rest. > > > > So far, I have experimented with simply adding the multiple genres > > as a text string delimited only with spaces (as in the earlier > > example). This seems to work OK for now, since I typically am > > searching for files with TCON containing a certain substring. Is > > this a robust use of the TCON frame? Are there rules/guidelines for > > entering multiple values into a Text Information Frame? > > Discussed above. > > > > One other question (which will show off what a newbie I am): > > > > What is the essential difference(s) between Text Information Frames > > (TALB, TBPM, ...) and Comments Frames. As best I can tell, a Text > > Information Frame is to contain a single string of text, with no > > carriage returns allowed. A Comments Frame can contain carriage > > returns (newlines). Is that the essential difference? > > Not quite... the T*** frames indeed can only contain a single text > string with no newlines, but COMM is more general than that. It is > basically a way for people (or programs) to stick arbittrary data into > the tag. iTunes uses COMM for their audio normalization flag among > other things. > > I would not expect COMMs to show up in various programs > consistently... But yes, the "actual text" field can contain > newlines. > > > > Also, is the USLT (Lyrics) frame type basically the same as a COMM > > frame, but simply with a specific purpose? > > Yes. > > -ben > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > > --------------------------------- > Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------- We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul_t100 at fastmail.fm Sat Mar 17 09:29:42 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 17 Mar 2007 16:29:42 +0000 Subject: AW: [ID3 Dev] 0-termination in text frames In-Reply-To: <823856.68352.qm@web27015.mail.ukl.yahoo.com> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> Message-ID: <45FC1776.9030300@fastmail.fm> I think it is unclear and unnecessary unless you are writing multiple strings in a v2.4 frame, so i never write them. The disadvantage of writing them is that players/taggers that dont realise that this null terminater should not be displayed display it as an undisplayable character, and also your additional not needed bytes. Mathias Kunter wrote: > Hello, > > well, I think it's clear. Version 2.2 and 2.3 specs say that data after a 0x00 byte (or 0x00 0x00 when using UTF16) in text frames should be ignored and not displayed. Version 2.4 says a 0 terminator separates substrings because every text frame allows multiple strings in 2.4. Well, I don't know if this is a common use-case anyway. > > So, if you write a 0 terminator at the end of the string, you definitely are on the safe side. A good ID3 parser should consider both the frame length and a possible existing earlier string terminator anyway when reading the tags. > > Regards, > Mathias > > > ----- Urspr?ngliche Mail ---- > Von: Florian Heidenreich > An: ID3v2 mailing list > Gesendet: Samstag, den 17. M?rz 2007, 13:20:36 Uhr > Betreff: [ID3 Dev] 0-termination in text frames > > Hi! > > I have one question regarding 0-termination in text frames because I > have the impression that the spec is not very clear on that. > > Should one write a terminating 0 (according to the text encoding) on > every text frame or not? > > Kind regards, > Florian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > > > > > ___________________________________________________________ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From s.a.johansen at usit.uio.no Fri Mar 16 06:32:55 2007 From: s.a.johansen at usit.uio.no (=?ISO-8859-1?Q?St=E5le_Asker=F8d_Johansen?=) Date: Fri, 16 Mar 2007 14:32:55 +0100 Subject: [ID3 Dev] Using multiple tags to specify genre and other traits. Message-ID: <45FA9C87.8010206@usit.uio.no> Hi. I'm new. This may be an old discussion, but important nonetheless. Historically, the "genre" has been the standard for specifying the "type" of music in an mp3-file. However, a piece of music will often belong to more than one genre. Moreover, people have not always agreed on which genres are needed to describe their music, so this has led to a plethora of more or less strange genres in use. It is time to move on. Structuring information is difficult. As a sysadmin trying to manage lots of different hosts with different roles, I meet this problem on a near daily basis. The solution is using multiple "roles", or "tags" to describe various "abilities" of something, whether it is webpages, music or servers. Over the last couple of years, using multiple "tags" has become a de facto standard in some internet communitites for structuring and categorizing webpages. A look at del.icio.us is a good example. This allows for much more fine-tuned selection criteria than just using a single variable. Let me give you an example. It's friday. I'm tired from a long week. I want to play some suitable music. Instead of choosing the genre "slow jazz", I want to choose jazz AND slow AND 70s AND instrumental AND NOT french AND NOT sad Tomorrow I'm having some guests over. For dinner we'd like some music. In want to choose (jazz OR classical) AND piano AND (norwegian OR swedish) AND NOT modern So. What do you think? My guess is that this won't be very difficult to code, the problem is to agree on a standard for this. Or is it a stupid, childish idea? -- St?le Johansen, Norway. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From support at mp3tag.de Sat Mar 17 13:27:49 2007 From: support at mp3tag.de (Florian Heidenreich) Date: Sat, 17 Mar 2007 21:27:49 +0100 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> <45FC2720.2050201@kde.org> <45FC4153.5070901@mp3tag.de> <45FC455A.2040405@fastmail.fm> <45FC4A2C.3080906@mp3tag.de> Message-ID: <45FC4F45.7060408@mp3tag.de> Dale Preston wrote: > While you're at it, I have seen some tags from MP3Tag that do not include > the three character language descriptor on comment tags. Has that been > fixed in later versions? Yes, I've fixed that while I was switching from id3lib to my own tagging library :) Kind regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Tue Mar 6 12:59:19 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 6 Mar 2007 15:59:19 -0500 Subject: [ID3 Dev] Clarifying the TCON Frame In-Reply-To: <20070306165544.92702.qmail@web53508.mail.yahoo.com> References: <20070306160911.GA19922@ayup.limey.net> <20070306165544.92702.qmail@web53508.mail.yahoo.com> Message-ID: <20070306205919.GA29340@ayup.limey.net> Yeah, it is a maze of twisty passages, all alike ;-) My rule of thumb is to try iTunes to see what they do (although their 2.4 implementation has some nasty bugs), and test that against winamp for 2.3 support and amarok (which uses a newer fancy id3 2.4 library). As long as you are willing to use a subset of the spec, and don't stray too far into the wilds, things will go well. -ben On Tue, Mar 06, 2007 at 08:55:44AM -0800, John Slane wrote: > Thanks very much for your patient and thorough answers. You have cleared up most of the confusion I had, and I feel ready to design a way to fit my metadata into ID3v2.3 tags that will be handled by a majority of apps. > > I must say, this task was more complex than I expected, given the nonuniform way that the ID3 tags are exploited by various apps. Without your help, I would have little confidence in proceeding. > > Thanks, again, for taking the time to help me out. > > Ben Bennett wrote: On Tue, Mar 06, 2007 at 05:42:23AM -0800, John Slane wrote: > ... > > The various music-management software I am using (MediaMonkey, > > Mp3tag, etc.) are writing alphanumeric (English words) data to this > > type (Genre) frame. So I would like to clarify a few things. > > > > (1) Is a TCON frame really supposed to contain a numeric string? If > > so, what is the definition of a "numeric string"? > > > The 2.3 version of TCON is a mess. 2.4 made some changes, but it is > still a bit tricky. > > It should not contain just a numeric string. > > The format is optional parenthesized genre reference e.g.: (4) > Then an optional textual refinement e.g.: Eurodisco > > There can be multiple references in the frame, and there are rules for > escaping (s. There is no mention of multiple refinements, I would > assume only one, and at the end of the string. > > You can also make references to RX for remix and CR for cover. > > So these are legal strings: > (4) > (4)Euro Disco > Euro Disco > (21)(4)(RX)Euro Disco > > > > (2) If I have English words in a TCON frame > > e.g. TCON = Soul R&B Motown > > will that cause a problem with any apps down the road? > > I think that is the safest and sanest thing to do. I would not use > the references stuff. iTunes puts just bare text in the frame and > does not handle lists. And since iTunes is widely used, I would > assume other software tries to read their tags. > > > > (3) If alphanumeric words are allowed, what is the best way to > > delimit multiple values in the frame? Are there any characters - > > delimiters or otherwise - that should be avoided in a TCON frame? > > I do not think you can... the frame can not be repeated, and there is > no identification of a list separator in that frame. The only > possible thing would be to do: > (4)Euro Disco(32)Duck Themed > > But I bet that is not well supported. > > However, you can indicate multiple genres through textual convention: > Euro Disco; Duck Theme > Euro Disco -- Duck Theme > Euro Disco / Duck Theme > > Just pick what you think is most visually correct. > > 2.4 has proviisions for multiple values (using NUL as a separator). > But I think most software just shows the first value and ignores the > rest. > > > > So far, I have experimented with simply adding the multiple genres > > as a text string delimited only with spaces (as in the earlier > > example). This seems to work OK for now, since I typically am > > searching for files with TCON containing a certain substring. Is > > this a robust use of the TCON frame? Are there rules/guidelines for > > entering multiple values into a Text Information Frame? > > Discussed above. > > > > One other question (which will show off what a newbie I am): > > > > What is the essential difference(s) between Text Information Frames > > (TALB, TBPM, ...) and Comments Frames. As best I can tell, a Text > > Information Frame is to contain a single string of text, with no > > carriage returns allowed. A Comments Frame can contain carriage > > returns (newlines). Is that the essential difference? > > Not quite... the T*** frames indeed can only contain a single text > string with no newlines, but COMM is more general than that. It is > basically a way for people (or programs) to stick arbittrary data into > the tag. iTunes uses COMM for their audio normalization flag among > other things. > > I would not expect COMMs to show up in various programs > consistently... But yes, the "actual text" field can contain > newlines. > > > > Also, is the USLT (Lyrics) frame type basically the same as a COMM > > frame, but simply with a specific purpose? > > Yes. > > -ben > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > > --------------------------------- > Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From support at mp3tag.de Sat Mar 17 05:20:36 2007 From: support at mp3tag.de (Florian Heidenreich) Date: Sat, 17 Mar 2007 13:20:36 +0100 Subject: [ID3 Dev] 0-termination in text frames Message-ID: <45FBDD14.70608@mp3tag.de> Hi! I have one question regarding 0-termination in text frames because I have the impression that the spec is not very clear on that. Should one write a terminating 0 (according to the text encoding) on every text frame or not? Kind regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Sat Mar 17 14:07:04 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Sat, 17 Mar 2007 21:07:04 +0000 (GMT) Subject: AW: [ID3 Dev] 0-termination in text frames Message-ID: <220332.96342.qm@web27001.mail.ukl.yahoo.com> >I think it is just saying that if you use a null terminated string then >you should terminate correctly for the encoding you use. > does not include a null terminator, >where a null terminator is required it is explicity stated in the spec >as these extracts show. Yup, I agree. For ID3 2.2 and 2.3 store a null terminated string. For 2.4, don't write a 0 terminator for the last substring of a text frame since the 0 is defined as separator here. It also wouldn't make much sense the other way. Look at the following example of a ISO-coded 2.4 text frame: string1 0x00 string2 0x00 string3 0x00 It simply would be inconsistent to treat the first two 0 bytes as separators and the last 0 byte as terminator. Therefore, code it as string1 0x00 string2 0x00 string3 Well, in practice it probably doesn't make much difference. If a 2.4 parser reads a text frame which contains a final 0x00 byte and there is no text to follow after it because the frame has been fully decoded now, it would be nonsense to treat that as "substring of zero length". Who would ever want to maintain a zero length string!? Therefore, just ignore it from the decoder point of view. I think the more important thing to consider is how other programs handle that and if they can well read the tags. A poorly written parser may expects to encounter a terminator of the last (or only) substring in a 2.4 frame. If it isn't there, it may skips the frame (although it would be correctly coded from the specs point of view). Because a zero length string (when otherwise interpreted as separator) doesn't really matter, it generally may even be more compatible to although write the last 0x00 terminator to a 2.4 frame (and "violating" the specs). I don't know a concrete program or parser which behaves that way, but it would be possible. Make your choice between (possible) compatibility improvement <--> (small) violation of the specs. Best regards. Mathias ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Fri Mar 23 11:43:02 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 23 Mar 2007 18:43:02 +0000 (GMT) Subject: [ID3 Dev] Compressed ID3 frames!? Message-ID: <900931.3737.qm@web27011.mail.ukl.yahoo.com> Does actually nobody care about this..? Regards Mathias ----- Urspr?ngliche Mail ---- Von: Mathias Kunter An: id3v2 at id3.org Gesendet: Donnerstag, den 22. M?rz 2007, 11:06:23 Uhr Betreff: [ID3 Dev] Compressed ID3 frames!? Hi there, I've got a question. ID3 version 2.3 and 2.4 define the ability to compress single frames with zlib. I've NEVER seen anybody who actually does this. My question now: do you know of any software which writes compressed ID3 frames?? Did you implement support for compressed frames in your tagging libraries, or is it useless to support this feature because nobody cares about compressed frames anyway? Thanks. Mathias ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jwhite at cdtag.com Tue Mar 20 19:46:59 2007 From: jwhite at cdtag.com (Jud White) Date: Tue, 20 Mar 2007 21:46:59 -0500 Subject: [ID3 Dev] Test Suite In-Reply-To: References: Message-ID: <46009CA3.1060903@cdtag.com> There's a tag archive you can get here: http://cdtag.com/tags/id3tags.7z Trevor Summers Smith wrote: > Hello, > > I'm working on a library to read and write ID3v2 tags, and am wondering if > anyone is aware of a comprehensive, or even sizable, testing suite. I've > looked around and found some examples in the libraries listed on the > id3.org website, but nothing very large. > > If such a thing has not yet been done, I'd be interested in gathering > examples and putting such a thing together, as I think it would be a > valuable tool for the developer community. > > Thanks, > > Trevor Smith > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Sat Mar 17 09:25:56 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Sat, 17 Mar 2007 12:25:56 -0400 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <823856.68352.qm@web27015.mail.ukl.yahoo.com> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> Message-ID: <20070317162556.GA1663@ayup.limey.net> On Sat, Mar 17, 2007 at 03:22:56PM +0000, Mathias Kunter wrote: > well, I think it's clear. Version 2.2 and 2.3 specs say that data > after a 0x00 byte (or 0x00 0x00 when using UTF16) in text frames > should be ignored and not displayed. Version 2.4 says a 0 terminator > separates substrings because every text frame allows multiple > strings in 2.4. Yes, but be careful... with some string types the terminator is two nul bytes not one. > Well, I don't know if this is a common use-case anyway. The 2.4 implementations I've seen do not handle multiple substrings (amarok, itunes). > So, if you write a 0 terminator at the end of the string, you > definitely are on the safe side. For 2.3 that is certainly true, but I am not so sure in the case of 2.4. If you have a terminator following the value then doesn't that imply a 0-length item? > A good ID3 parser should consider both the frame length and a > possible existing earlier string terminator anyway when reading the > tags. Agreed. So, I would avoid terminating strings in both 2.3 and 2.4. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Fri Mar 16 11:05:14 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 16 Mar 2007 18:05:14 +0000 (GMT) Subject: [ID3 Dev] Using multiple tags to specify genre and other traits. Message-ID: <570318.50180.qm@web27006.mail.ukl.yahoo.com> For all of the things you mentioned already exist defined ID3 frames. The TMOO frame is for the mood of an audio file (since ID3 version 2.4): "slow" and "sad", for example. "70ies" would be coded as year in the TYER frame (ID3 version 2.3), or in the TDRC frame in ID3 version 2.4. The TLAN frame holds information about the language(s) of the file. And as Tom already said, the TCON frame stores one or more associated genres. I agree that it would be cool to define custom "flags" which can be used to define if a particular MP3 file is something or is something not (for example, can you hear a piano playing in it, or whatever). Such information is not well placed within the TMOO frame, and this frame also only exists in the less popular ID3 version 2.4. But since such information is completely subjective (because everybody can define his/her own "flags") it makes no sense to include something like that in the specification. There is the TXXX frame for storing any user-defined information within the ID3 tag which you could think of. But as long as nobody else than you uses them to store "if the piano is playing in this song" it doesn't make much sense except for your own use. If you tag all your music files with such user-defined information, it might be helpful for you, of course, but not for other people because they wouldn't know how to interpret this subjective information you entered (generally seen). As I said before, some standardized frames exist for the most relevant metadata. However, even these frames are actually not really important. Most people simply don't care to enter which mood a song is or if a piano is playing in this track. Genre information is usually there, but the info within this field is often incorrect. To summarize, these metadata fields you suggested to include within the standard are too subjective and irrelevant as they would ever be of any benefit. There even exist many files which have entered "Track07" as track name. Just think of how much people would care entering your subjective data if they don't even enter correct artist and track names. Cheers Mathias ----- Urspr?ngliche Mail ---- Von: St?le Asker?d Johansen An: id3v2 at id3.org Gesendet: Freitag, den 16. M?rz 2007, 14:32:55 Uhr Betreff: [ID3 Dev] Using multiple tags to specify genre and other traits. Hi. I'm new. This may be an old discussion, but important nonetheless. Historically, the "genre" has been the standard for specifying the "type" of music in an mp3-file. However, a piece of music will often belong to more than one genre. Moreover, people have not always agreed on which genres are needed to describe their music, so this has led to a plethora of more or less strange genres in use. It is time to move on. Structuring information is difficult. As a sysadmin trying to manage lots of different hosts with different roles, I meet this problem on a near daily basis. The solution is using multiple "roles", or "tags" to describe various "abilities" of something, whether it is webpages, music or servers. Over the last couple of years, using multiple "tags" has become a de facto standard in some internet communitites for structuring and categorizing webpages. A look at del.icio.us is a good example. This allows for much more fine-tuned selection criteria than just using a single variable. Let me give you an example. It's friday. I'm tired from a long week. I want to play some suitable music. Instead of choosing the genre "slow jazz", I want to choose jazz AND slow AND 70s AND instrumental AND NOT french AND NOT sad Tomorrow I'm having some guests over. For dinner we'd like some music. In want to choose (jazz OR classical) AND piano AND (norwegian OR swedish) AND NOT modern So. What do you think? My guess is that this won't be very difficult to code, the problem is to agree on a standard for this. Or is it a stupid, childish idea? -- St?le Johansen, Norway. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Fri Mar 23 12:08:50 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 23 Mar 2007 15:08:50 -0400 Subject: [ID3 Dev] Compressed ID3 frames!? In-Reply-To: <900931.3737.qm@web27011.mail.ukl.yahoo.com> References: <900931.3737.qm@web27011.mail.ukl.yahoo.com> Message-ID: <20070323190850.GA32024@ayup.limey.net> I support readiing and writing it in the perl id3 parser I wrote, but I would not write compressed stuff out if I expected it to be portable. So, compression is off by default in my lib. -ben On Fri, Mar 23, 2007 at 06:43:02PM +0000, Mathias Kunter wrote: > Does actually nobody care about this..? > > Regards > Mathias > > > > ----- Urspr?ngliche Mail ---- > Von: Mathias Kunter > An: id3v2 at id3.org > Gesendet: Donnerstag, den 22. M?rz 2007, 11:06:23 Uhr > Betreff: [ID3 Dev] Compressed ID3 frames!? > > Hi there, > > I've got a question. ID3 version 2.3 and 2.4 define the ability to compress > single frames with zlib. I've NEVER seen anybody who actually does this. > My question now: do you know of any software which writes compressed > ID3 frames?? > > Did you implement support for compressed frames in your tagging libraries, > or is it useless to support this feature because nobody cares about > compressed frames anyway? > > > Thanks. > Mathias > > > > > > > ___________________________________________________________ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > > > > > > ___________________________________________________________ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From paul_t100 at fastmail.fm Sat Mar 17 12:45:30 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 17 Mar 2007 19:45:30 +0000 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <45FC4153.5070901@mp3tag.de> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> <45FC2720.2050201@kde.org> <45FC4153.5070901@mp3tag.de> Message-ID: <45FC455A.2040405@fastmail.fm> Florian Heidenreich wrote: > I'm still not sure about the issue. The ID3v2.4 spec from > http://id3.org/id3v2.4.0-structure presents a list of possible encodings > at '4. ID3v2 frame overview' where the terminating 0 is explicitly > included in every text string: > > > Frames that allow different types of text encoding contains a text > encoding description byte. Possible encodings: > > $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. > $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All > strings in the same frame SHALL have the same byteorder. > Terminated with $00 00. > $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. > Terminated with $00 00. > $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. > > > According to that list it seems to me, that every string includes a > terminating $00 (or $00 00 when using UTF-16). > > What do you think about it? > > Thank you! > > Kind regards, > Florian > > I think it is just saying that if you use a null terminated string then you should terminate correctly for the encoding you use. does not include a null terminator, where a null terminator is required it is explicity stated in the spec as these extracts show. In the first case it states the items should be seperated by a null character, so there shouldnt be a null character for the last entry because it is not seperating anything. In the second case a null terminator is always needed to seperate the description from the value. 4.2. Text information frames The text information frames are often the most important frames, containing information like artist, album and more. There may only be one text information frame of its kind in an tag. All text information frames supports multiple strings, *stored as a null separated list,* *where null is reperesented by the termination code for the charater encoding.* 4.2.6. User defined text information frame Text encoding $xx Description *$00 (00)* Value --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Sat Mar 17 12:44:24 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Sat, 17 Mar 2007 15:44:24 -0400 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <45FC4153.5070901@mp3tag.de> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> <45FC2720.2050201@kde.org> <45FC4153.5070901@mp3tag.de> Message-ID: <20070317194424.GB14841@ayup.limey.net> On Sat, Mar 17, 2007 at 08:28:19PM +0100, Florian Heidenreich wrote: > I'm still not sure about the issue. The ID3v2.4 spec from > http://id3.org/id3v2.4.0-structure presents a list of possible encodings > at '4. ID3v2 frame overview' where the terminating 0 is explicitly > included in every text string: > > > Frames that allow different types of text encoding contains a text > encoding description byte. Possible encodings: > > $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. > $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All > strings in the same frame SHALL have the same byteorder. > Terminated with $00 00. > $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. > Terminated with $00 00. > $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. > > > According to that list it seems to me, that every string includes a > terminating $00 (or $00 00 when using UTF-16). I think you are misinterpreting that. That is where they are telling you what the termination character for that string type is. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Wed Mar 28 04:59:11 2007 From: wheeler at kde.org (Scott Wheeler) Date: Wed, 28 Mar 2007 13:59:11 +0200 Subject: [ID3 Dev] Suggestion for 2.4.1 - TAGS In-Reply-To: <460A4C35.4070806@usit.uio.no> References: <570318.50180.qm@web27006.mail.ukl.yahoo.com> <45FE7BD2.3070302@usit.uio.no> <20070319140233.GA2249@ayup.limey.net> <460A4C35.4070806@usit.uio.no> Message-ID: <460A588F.40006@kde.org> St?le Asker?d Johansen wrote: > I'd hereby like to suggest another field be added to the ID3V2 spec [...] It's taken more than half a decade to have 2.4.0 reasonably well supported. I wouldn't count on folks jumping on board for a new version. The only thing that's been seriously considered is a revision of the spec to clear up some ambiguities and even at that, I don't think there's anyone doing concrete work on such. -Scott --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From s.a.johansen at usit.uio.no Mon Mar 19 05:02:26 2007 From: s.a.johansen at usit.uio.no (=?ISO-8859-1?Q?St=E5le_Asker=F8d_Johansen?=) Date: Mon, 19 Mar 2007 13:02:26 +0100 Subject: [ID3 Dev] Using multiple tags to specify genre and other traits. In-Reply-To: <570318.50180.qm@web27006.mail.ukl.yahoo.com> References: <570318.50180.qm@web27006.mail.ukl.yahoo.com> Message-ID: <45FE7BD2.3070302@usit.uio.no> Mathias Kunter wrote: > For all of the things you mentioned already exist defined ID3 frames. > The TMOO frame is for the mood of an audio file (since ID3 version 2.4): > "slow" and "sad", for example. > "70ies" would be coded as year in the TYER frame (ID3 version 2.3), or in the > TDRC frame in ID3 version 2.4. > The TLAN frame holds information about the language(s) of the file. > And as Tom already said, the TCON frame stores one or more associated genres. > I think I need to elaborate. My point is that i do NOT want separate frames for all the different things one might want to register. Not this: [TLAN]: norwegian, british, hawaiian, french [TYER]: 1980, 1965, 2003, 1999 [TMOO]: sad, happy, bouncy, slow, fast, joyful [TCON]: rock, pop, balkan-brass, classical, noseflute But this: [TAGS]: rock, folk, instrumental, oldie, sorrowful, slow, piano, violin, swedish, scandinavian, progressive, 70s, 1971, soundtrack > > To summarize, these metadata fields you suggested to include within the > standard are too subjective and irrelevant as they would ever be of any > benefit. There even exist many files which have entered "Track07" as track > name. Just think of how much people would care entering your > subjective data if they don't even enter correct artist and track names. > A very good point, and I realize that this information often will have to be entered and used by each user based on personal taste. An alternative is to make something wiki-like where people can collaborate on making a common framework, like for instance del.icio.us. -- St?le --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From support at mp3tag.de Sat Mar 17 13:06:04 2007 From: support at mp3tag.de (Florian Heidenreich) Date: Sat, 17 Mar 2007 21:06:04 +0100 Subject: [ID3 Dev] 0-termination in text frames In-Reply-To: <45FC455A.2040405@fastmail.fm> References: <823856.68352.qm@web27015.mail.ukl.yahoo.com> <20070317162556.GA1663@ayup.limey.net> <45FC2720.2050201@kde.org> <45FC4153.5070901@mp3tag.de> <45FC455A.2040405@fastmail.fm> Message-ID: <45FC4A2C.3080906@mp3tag.de> Paul Taylor wrote: > Florian Heidenreich wrote: >> I'm still not sure about the issue. The ID3v2.4 spec from >> http://id3.org/id3v2.4.0-structure presents a list of possible >> encodings at '4. ID3v2 frame overview' where the terminating 0 is >> explicitly included in every text string: >> >> >> Frames that allow different types of text encoding contains a text >> encoding description byte. Possible encodings: >> >> $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. >> $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All >> strings in the same frame SHALL have the same byteorder. >> Terminated with $00 00. >> $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. >> Terminated with $00 00. >> $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. >> >> >> According to that list it seems to me, that every string includes a >> terminating $00 (or $00 00 when using UTF-16). >> >> What do you think about it? >> >> Thank you! >> >> Kind regards, >> Florian >> >> > I think it is just saying that if you use a null terminated string then > you should terminate correctly for the encoding you use. > does not include a null terminator, > where a null terminator is required it is explicity stated in the spec > as these extracts show. [..] Thanks for the clarification! It seems that I'll have to change Mp3tag's ID3 writer :) Kind regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jwhite at cdtag.com Sat Mar 3 18:43:23 2007 From: jwhite at cdtag.com (Jud White) Date: Sat, 03 Mar 2007 20:43:23 -0600 Subject: [ID3 Dev] User-Defined Frames In-Reply-To: <283328.6459.qm@web53514.mail.yahoo.com> References: <283328.6459.qm@web53514.mail.yahoo.com> Message-ID: <45EA324B.902@cdtag.com> 1. Yes, text in TCON is compliant. It's not defined as only a numeric string. 2. The preferred way to delimit genres is with a null terminator, although only a few apps/libs support this. There's no reason spaces should break another reader. 3. TIT1 might be good for "Theme", if your software writes this frame. The definition for TIT1: "The 'Content group description' frame is used if the sound belongs to a larger category of sounds/music. For example, classical music is often sorted in different musical sections (e.g. "Piano Concerto", "Weather - Hurricane").". If not, TXXX seems most appropriate, but you mentioned MM doesn't support these either. Foobar definitely allows TXXX. I would stay away from using COMM, because it's not a comment, although iTunes and other software abuse this frame liberally. 4. It doesn't break the spec that MM writes its own COMM identifiers, but it is messy IMO. I wouldn't worry about it breaking another app, but I would doubt another app would treat a MM COMM frame as anything other than a comment. 5. TXXX is appropriate if you want to define your own metadata. A populer one is "Album Artist" for compilation CD's. So you could have TXXX/Album Artist/DJ Dara, for example. COMM is meant for comments, maybe some notes about a live recording, or a press release about a CD, etc. If you use proprietary descriptors in COMM then you're righ to worry about lock-in. You may be able to find someone willing to write a conversion utility to take COMM/MediaMonkey frames and translate them into whatever you're looking for in the future. John Slane wrote: > As you will be able to infer, I am pretty much a newbie to mp3 and > ID3. I am about to begin tagging a few thousand mp3 files, and I sure > would like to get it right the first time. I've read through the > ID3v2.3 standard and I have experimented with modifying tags using > mp3Tag and MediaMonkey. I look at how each program modified the tag > by reading the tag with id3.exe. While I believe I understand the > basics now, I have a couple of nagging questions that remain, and I > hope that you can kindly help me out. > > I want to use tag metadata to build "AutoPlaylists" in MediaMonkey. > Basically, I'd like to be able to tell my jukebox - for example - to > play songs from 1968 that have the Genre = Soul or Funk AND the Theme > = Cars or Dancing. This idea raises a few issues: > > (1) A TCON (genre) frame in ID3v2.3 is defined as a numeric string. I > notice, though, that both MediaMonkey and mp3Tag write alphabetic > words into this frame (as confirmed by id3.exe). Is this in > conformity with the spec, and might it cause any problem with reading > the tag in other programs? > > (2) Although only one TCON frame is allowed per tag, I was able to > write multiple genre values into the TCON frame, simply by writing > them as a string, delimiting them with spaces or other characters. > MediaMonkey is able to then search on any portion of the string to > make a playlist. Is there any potential problem (with any tag-reading > software) that arises from putting multiple genre values into the > single TCON frame? > > (3) Now I come to my "Theme" field. Since there is no declare Theme > frame type in ID3 and no Theme field in MediaMonkey, I could sneak > "Theme" values into one of MediaMonkey's predefined fields that I do > not use; but it would, of course, be mislabeled. On the other hand, I > could put my "Theme" values into a TXXX or a COMM frame. MediaMonkey > does not create or recognize any TXXX frames, but it does offer a few > user-defined COMM fields (Custom1 - Custom3). So I could use one of > these, and use the Descriptor "Theme," and enter my multiple-valued > theme data in as a string, with whatever delimiters seem appropriate. > Does that make sense? Are there any kind of rules for choosing > delimiters, in terms of compatibility with the world of software out > there? > > (4) When I do use one of MediaMonkey's "user-defined" COMM fields, I > note that MediaMonkey imposes its own descriptor on the tag frame. > For example, if I enter "January" into user-defined field "Custom 1", > I get the following tag frame: > COMM = Songs-DB_Custom1 January. > So MediaMonkey has predefined descriptors that it uses for its > "user-defined" fields/frames. These fields seem to work just fine > within MediaMonkey, for making playlists, etc. But will they cause > problems for me in the future if I migrate my music collection to > another jukebox software or some other software application? I fear > that using the MediaMonkey jargon in the tag will cause me recognition > problems elsewhere. > > (5) Considering Issues (2) and (3) together, I wonder about the > difference between a text frame and a comment frame. For example, how > are a TXXX and a COMM actually different (so I know which to choose > for what). Each one can have multiple occurrences in the same tag; > each one takes a descriptor to distinguish it from its kin in the same > tag; and each one accepts a text string as its actual data. So how > are they different? Does one allow a LONGER string, or broader > formatting, or what? I'd like to know when a TXXX is appropriate, and > when a COMM is appropriate. > > As you can see, I'm trying to figure out how to cram non-standard > information (multiple genres, music themes, months of the year) into > my ID3v2.3 tags. And my current jukebox (MediaMonkey) apparently > gives my a couple of options for doing this, but they seem rather > limited, and I worry that using them will tie me to this application > for the rest of my life (unless I want to retag thousands of files). > Any general advice you can offer on making universally acceptable tags > that contain non-standard metadata will be greatly appreciated. > > Thanks for your patience in reading all this, and for any advice you > might have on any or all of these issues. I feel a bit overwhelmed at > the moment, and reluctant to begin tagging my collection until I get a > bit more comfortable. > > jaslane64 > Dublin Ohio > > ------------------------------------------------------------------------ > TV dinner still cooling? > Check out "Tonight's Picks" > on Yahoo! TV. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Sat Mar 17 08:22:56 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Sat, 17 Mar 2007 15:22:56 +0000 (GMT) Subject: AW: [ID3 Dev] 0-termination in text frames Message-ID: <823856.68352.qm@web27015.mail.ukl.yahoo.com> Hello, well, I think it's clear. Version 2.2 and 2.3 specs say that data after a 0x00 byte (or 0x00 0x00 when using UTF16) in text frames should be ignored and not displayed. Version 2.4 says a 0 terminator separates substrings because every text frame allows multiple strings in 2.4. Well, I don't know if this is a common use-case anyway. So, if you write a 0 terminator at the end of the string, you definitely are on the safe side. A good ID3 parser should consider both the frame length and a possible existing earlier string terminator anyway when reading the tags. Regards, Mathias ----- Urspr?ngliche Mail ---- Von: Florian Heidenreich An: ID3v2 mailing list Gesendet: Samstag, den 17. M?rz 2007, 13:20:36 Uhr Betreff: [ID3 Dev] 0-termination in text frames Hi! I have one question regarding 0-termination in text frames because I have the impression that the spec is not very clear on that. Should one write a terminating 0 (according to the text encoding) on every text frame or not? Kind regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Thu Mar 22 03:06:23 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Thu, 22 Mar 2007 10:06:23 +0000 (GMT) Subject: [ID3 Dev] Compressed ID3 frames!? Message-ID: <213010.26334.qm@web27012.mail.ukl.yahoo.com> Hi there, I've got a question. ID3 version 2.3 and 2.4 define the ability to compress single frames with zlib. I've NEVER seen anybody who actually does this. My question now: do you know of any software which writes compressed ID3 frames?? Did you implement support for compressed frames in your tagging libraries, or is it useless to support this feature because nobody cares about compressed frames anyway? Thanks. Mathias ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org