From wheeler at kde.org Thu Mar 2 06:42:23 2006 From: wheeler at kde.org (Scott Wheeler) Date: Thu, 2 Mar 2006 15:42:23 +0100 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <1836.213.81.187.20.1141304050.squirrel@213.81.187.20> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> <1836.213.81.187.20.1141304050.squirrel@213.81.187.20> Message-ID: <200603021542.24534.wheeler@kde.org> On Thursday 02 March 2006 13:54, Michal Vician wrote: > First I wanted to implement ID3v2 as "widely" as possible. Now my > application supports 39 ID3v2 frames and I'm angry that I can't write it > to other audio file formats :-( What a pity... > > I'm curious if there is a way to "translate" all ID3v2 frames (APIC, ...) > to "Xiph Comments" etc... If there is no way, I must only admit that my > application will never support other format than MP3. No, there's no way to do direct mappings. Especially with the example that you mention -- APIC -- there's no way to store images in Ogg Vorbis's standard metadata format; the "Xiph Comments" are just key-value text. i.e. "ARTIST=Frank Zappa". That said, I think taggers should abstract away most of the differences. I don't know of many users that say, "I want to set the TCON frame of my ID3v2 tag", rather they say, "I want to set the genre." If things are kept abstract enough, it's relatively easy to disable parts of the interface that are not relevant for a specific file, or to store the extra pieces of information in an external meta-data cache (and then simply notify the users that the information will not be accessible in other applications. For the most part, in practical terms that's true with the more obscure ID3v2 fields because the majority of applications completely ignore them anyway. -Scott -- The world is full of magical things patiently waiting for our wits to grow sharper. --Bertrand Russell --------------------------------------------------------------------- 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 Mon Mar 20 13:49:43 2006 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 20 Mar 2006 21:49:43 +0000 Subject: [ID3 Dev] ID3 Testing certification or testing framework Message-ID: <441F2377.108@fastmail.fm> There has been alot of ideas regarding a new version of ID3 recently but it seems to me the key thing required is a certification scheme whereby existing applications (tagger/players/burners) could be certified as being id3 compatible (you would probably need different levels of compatability). If such a thing was introduced i would hope there would be some commercial organisations willing to partially fund it as the ID3 must carry some kudos. Certification of this would reward applications that try to adhere to the spec and should eventually lead to an improvements in compatability. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From pfurrie at hotmail.com Sat Mar 4 14:11:01 2006 From: pfurrie at hotmail.com (Pat Furrie) Date: Sat, 4 Mar 2006 17:11:01 -0500 Subject: [ID3 Dev] New genre coding idea? In-Reply-To: <20060304213958.XATJ4651.gx5.fuse.net@avoca> Message-ID: Mitch, Thanks for your reply. At one point it was determined that the functionality of ID3v1 was insufficient to meet people?s needs. It?s time to address the deficiencies of the current genre model in some way. While the need for exotic genre naming schemes might be outside the realm of an orderly standardized word set, we should also question the usefulness of retaining functionality which I suspect is seeing limited use. You?re right ? those people with ?Venezuelan Beaver Chill Out Groove? might not be able to have that precise set of terms, though ?Venezuelan,? ?Chill,? and ?Groove? would probably be in the list, and you?d have them spelled the same, correct way every time; who knows how many different ways people would misspell ?Venezuelan.? This is helpful when you share your music collection with me, and my software doesn?t have to include some funky new custom genre (one which I?d otherwise never use, or might be spelled differently than my version. Now I know that your groove music will be sorted correctly with my groove music ? cool! As for ?Mitch?s Favs?, it should be expressed by virtue of a rating value, the sort of thing so many audio library programs already use. It would be great -- when I buy an MP3 online ? for it to have a bunch of genre and modifier selections already selected, saving me the effort of having to go classify them all myself. But if the classification system can?t be localized, it makes it less useful for handling everyone. One way to rectify the backward compatibility issue: this is just another genre list. Just as some files have genre information recorded in both the ID3v1 and ID3v2 tags simultaneously, this adds another option of functionality. It?s not as elegant, but it doesn?t break anything either. Pat _____ From: Mitchell S. Honnert [mailto:mitch at honnert.com] Sent: Saturday, March 04, 2006 4:40 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] New genre coding idea? Pat, it?s obvious you put a lot of thought into this proposal, but I think there?s a ?showstopper? item missing from your Disadvantages list. Converting the existing genre frame to support a bitmap style representation of multiple genres would break backward compatibility. The ID3 standard has had free-form genres for so long, it?d be next to impossible to go back to using a fixed list, even one that allowed for modified pairs like you described. For example, if your proposal were adopted, how should an ID3-compatible program handle the genre of ?Venezuelan Beaver Cheese Chill Out Groove? or even ?Mitch?s Favs?. You just never know what people have put in the Genre field, so there?s really no way to convert these values and go back to a fixed set of values. The genie is out of the bottle, so to speak. However, this doesn?t mean that we can?t clarify the genre frame specification to promote the use of multiple genres. The only application that I?ve found that supports multiple genres is ID3-TagIT. It uses what I think is the simplest, best approach for multiple genres which is simply using a null char delimited list of genre values. In fact, I?ve adopted its format in my own ID3 library, UltraID3Lib.) This technique has the benefit of being backward compatible with all ID3v2 versions. (Apps should just ignore anything after the first null char delimiter, so they wouldn?t fully support the format, but neither would this format break compatibility.) Anyway, not that I want to be such a downer, but I think it?s too late to go to a limited set of genre values. There are just too many weird genres out there to ever be codified in a manageable list. Mitchell S. Honnert www.UltraID3Lib.com _____ From: Pat Furrie [mailto:pfurrie at hotmail.com] Sent: Saturday, March 04, 2006 3:31 PM To: id3v2 at id3.org Subject: [ID3 Dev] New genre coding idea? I?ve been considering how multiple genres can be assigned via ID3. What I do understand: 1) ID3v1 had a single byte which mapped to a fixed and limited list of genres. 2) ID3v2 allows for a genre frame which can have some mix of genres. 3) Very few programs, if any, are using the multiple genre capability. 4) Programs like iTunes seem to allow multiple genres, but in reality users are only creating a new genre which is the composite of existing types. However there is no cross-referencing: I can give an MP3 the ?genre? of ?rock soundtrack? but if I list everything in the ?rock? or ?soundtrack? genres, it doesn?t show up. Additionally, ?soundtrack, rock? is not equivalent to ?rock, soundtrack? in the iTunes world. One way of dealing with it is to utilize free-form text with delimiters, allowing users to enter as many of whatever genres they come up with. However, this has a few problems: 1) Because the length of the field is unknown, padding must be used, and the possibility still exists of needing to re-write the rest of the file due to exceeding the space given by any padding. 2) Any spelling errors create additional genres when they shouldn?t exist (does ?soundtrack? equal ?sound track??) 3) What works for English doesn?t work for other languages. Localization is difficult. The original one-byte method in ID3v1 did have the potential of being able to be localized, since the genre name lookup table could be altered for whatever the user?s language is. But it only allows a single genre, and it is easy to show that most files (of any type) can be reasonably listed in multiple categories. Another solution is to use the same look-up table, but have multiple delimited values listed. Let?s bit-map the genre information. Make the bit-mapped switches correspond to smaller divisions of description as opposed to compounded versions. For example, terms like ?Rock,? ?Classic Rock,? ?AlternRock,? ?Instrumental Rock,? ?Gothic Rock,? ?Folk-Rock,? ?Progressive Rock,? ?Psychedelic Rock,? ?Southern Rock,? ?Symphonic Rock,? ?Hard Rock,? ?Slow Rock,? and ?Punk Rock? are replaced by ?Rock,? ?Classic,? ?Alternate,? ?Instrumental,? ?Gothic,? ?Folk,? Progressive,? ?Psychedelic,? ?Southern,? ?Symphonic,? ?Hard,? ?Slow,? and ?Punk.? Note that any of those terms can be combined with any of the others to give a larger variety of unique genres (ie, ?Instrumental Punk? and ?Southern Folk?), as well as with a myriad of other terms condensed from the current list of genres, and a host of additional modifiers and qualifiers. This atomized approach to the subjective art of classification allows for a far more expansive range of control and choice while keeping spellings and terms standardized. And while there are fewer than 150 genres in the more-or-less standard version, this new approach allows for, well? an awfully big number? 2 to the number of bits used in the bit map. After doing some digging up of genre types from the Internet, it seems 1000 bits should be sufficient. This includes a wide range of modifying terms and plenty of reserved space for the future. Doing a little rounding to come up with an even number, 150 bytes appears to be a good number to consider for the size of the reserved space. Bitmap Advantages: - Efficient. With a small amount of file space, a very large number of genres can be described. - Complete. A user can have any combination of a large number of genre and modifiers to describe each audio file. - Language independent. The bits map to terms which can be localized to a user?s language. - Can be cross-referenced. Files can easily be sorted on a single genre attribute or any combination. - Changes don?t ever affect a file?s size. Once the fixed-length bit-map has been attached, regardless of what genre/modifier values have been selected, genre changes will no longer have any impact on file size. - Standardized terms and spellings. A user has a hard enough time entering the same text each time exactly the same, let alone having different users entering textual genre information the same. Consistency in spelling and terms becomes possible when the choices are mapped to a fixed word list. - Room for term growth. The full list of genre switches wouldn?t be exhausted, leaving head-room for additional bit-mappable items to be added over time. Bitmap Disadvantages - No user-customized genres. This is the case with the ID3v1 scheme as well. However, the baseline list of proposed genres and modifiers is much more vast, and the freedom for creating any combination gives choices many orders of magnitude greater than before. Also, by having standardized genres, you can be sure that when you import an audio file with this scheme into your own database, the genres will mesh ? no ambiguity due to spelling, language, or word order (that is, ?soundtrack rock? will equal ?rock soundtrack?.) - Not ?human readable.? The genre and modifier data is bit-coded, so if a user were to open such a file with a text viewer/editor, they?d have difficulty making sense of it. However, most users never have the need to, know how to, or want to open audio files with a text editor. They?ll use software designed for viewing and editing the tags. Also, coded in hex, this could easily exist with an XML framework, if need be. - Always consumes 150 bytes. From a relative point-of-view, this is a big increase. This is a lot more than the 1 byte for ID3v1. However, from an absolute viewpoint, this isn?t much. For a user with ten-thousand MP3s, the total impact byte-wise is 1.5 megs. Using my collection of slightly more than ten-thousand MP3s as an example, it consumes just over forty gigabytes of disk space. 1.5 megs of additional space amounts to a percentage increase of less than 4 one-thousandths of one percent. -------------- Pat -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david_wu31 at yahoo.com Tue Mar 7 18:00:04 2006 From: david_wu31 at yahoo.com (danny amaz) Date: Tue, 7 Mar 2006 18:00:04 -0800 (PST) Subject: [ID3 Dev] about MP3 loyalty fee In-Reply-To: <440D4B8B.1080304@iis.fraunhofer.de> Message-ID: <20060308020004.4252.qmail@web53301.mail.yahoo.com> Thank you so much ! --- Oliver Baum wrote: > On 06.03.2006 19:11, danny amaz wrote: > > Does anybody know how to pay MP3 loyalty? > > See ! > (seems to be a little OT here...) > > > Regards, > > Oliver > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From thy at cult-of-noise.net Thu Mar 2 06:11:09 2006 From: thy at cult-of-noise.net (Thy Nae) Date: Thu, 2 Mar 2006 15:11:09 +0100 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <1836.213.81.187.20.1141304050.squirrel@213.81.187.20> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> <1836.213.81.187.20.1141304050.squirrel@213.81.187.20> Message-ID: <1cd7d6da0603020611ya51a147r@mail.gmail.com> > > I'm curious if there is a way to "translate" all ID3v2 frames (APIC, ...) > to "Xiph Comments" etc... If there is no way, I must only admit that my > application will never support other format than MP3. > Read your mp3 ,take an id3tag, eg:title, read his value and store it in a variable. Open your ogg/vorbis , create a tag called "title"=xxxxx , read the previous variable and replace xxxxx by the variable's content. Do it again with "author" , one more time with "author". That's all :-p The most difficult work is to write the match table; you have now to read some (boring) docs. Thy/ Manu B. -- "Si vous pensez que les hackers ne sont qu'une bande d'anarchistes pr?te ? tout mettre ? feu et ? sang parceque ?a les amuse , vous vous trompez du tout au tout : nous sommes bien pires que ?a" No One Is Innocent , Nomenklatura -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch at honnert.com Sat Mar 4 15:03:13 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 4 Mar 2006 18:03:13 -0500 Subject: [ID3 Dev] New genre coding idea? In-Reply-To: Message-ID: <20060304230310.XFTO4651.gx5.fuse.net@avoca> >At one point it was determined that the functionality of ID3v1 was insufficient to meet people's needs. But more importantly, at a later point - the creation of the ID3v2 standard, to be precise - it was determined that a fixed set of genre values was *not* sufficient to meet people's needs. In other words, at some point, the enough of the people who were determining the ID3v2 standard agreed that there was just no way to come up with a finite list of values for something so subjective as "Genre" so the best approach was to just let the field be free-form. >It's time to address the deficiencies of the current genre model in some way. While the need for exotic genre naming schemes might be outside >the realm of an orderly standardized word set, we should also question the usefulness of retaining functionality which I suspect is seeing limited use. What are these deficiencies to which you refer? I would agree that the vagueness of the standard around how to implement multiple genres has limited this functionality, but how is a free-form genre value - single or multiple - a deficiency? I can understand the appeal of having a uniform set of genres, but it would be highly impractical and outside the scope of this list to be responsible for perpetually maintaining an ever-changing list of genre values for every music category in the world. But this isn't a deficiency in the standard; it's just the nature of the concept of "genre". >Now I know that your groove music will be sorted correctly with my groove music - cool! But the assignment of what I think it "groove" or whatever is so subjective that even if you did come up with a grand master genre list, there's no guarantee that what I tagged as "groove" would be what you would tag a "groove". >As for "Mitch's Favs", it should be expressed by virtue of a rating value, the sort of thing so many audio library programs already use. I actually don't use genre in the fashion. I was using this as an example of how people might be currently using the genre field to categorize their music. It's all well and good to tell people that they shouldn't use the genre in this way, but it's another to change the standard so that ID3-compatible libraries and applications would drop your genre because it couldn't find a match in its master list. How do you think WinAmp users would feel if half their genres got erased because when rewriting their files, the ID3 library that it uses went to a new version of the standard that restricted what genres they were allowed to have? Do you think they'd appreciate losing their data in the name of conformity? Again, I can sympathize with your desire for a uniform set of genre values, but (as I think has been discussed in this list before) maintaining a list of something so subjective would be so impractical that any benefits would be far outweighed by the effort to maintain the list. - Mitchell S. Honnert _____ From: Pat Furrie [mailto:pfurrie at hotmail.com] Sent: Saturday, March 04, 2006 5:11 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] New genre coding idea? Mitch, Thanks for your reply. At one point it was determined that the functionality of ID3v1 was insufficient to meet people's needs. It's time to address the deficiencies of the current genre model in some way. While the need for exotic genre naming schemes might be outside the realm of an orderly standardized word set, we should also question the usefulness of retaining functionality which I suspect is seeing limited use. You're right - those people with "Venezuelan Beaver Chill Out Groove" might not be able to have that precise set of terms, though "Venezuelan," "Chill," and "Groove" would probably be in the list, and you'd have them spelled the same, correct way every time; who knows how many different ways people would misspell "Venezuelan." This is helpful when you share your music collection with me, and my software doesn't have to include some funky new custom genre (one which I'd otherwise never use, or might be spelled differently than my version. Now I know that your groove music will be sorted correctly with my groove music - cool! As for "Mitch's Favs", it should be expressed by virtue of a rating value, the sort of thing so many audio library programs already use. It would be great -- when I buy an MP3 online - for it to have a bunch of genre and modifier selections already selected, saving me the effort of having to go classify them all myself. But if the classification system can't be localized, it makes it less useful for handling everyone. One way to rectify the backward compatibility issue: this is just another genre list. Just as some files have genre information recorded in both the ID3v1 and ID3v2 tags simultaneously, this adds another option of functionality. It's not as elegant, but it doesn't break anything either. Pat _____ From: Mitchell S. Honnert [mailto:mitch at honnert.com] Sent: Saturday, March 04, 2006 4:40 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] New genre coding idea? Pat, it's obvious you put a lot of thought into this proposal, but I think there's a "showstopper" item missing from your Disadvantages list. Converting the existing genre frame to support a bitmap style representation of multiple genres would break backward compatibility. The ID3 standard has had free-form genres for so long, it'd be next to impossible to go back to using a fixed list, even one that allowed for modified pairs like you described. For example, if your proposal were adopted, how should an ID3-compatible program handle the genre of "Venezuelan Beaver Cheese Chill Out Groove" or even "Mitch's Favs". You just never know what people have put in the Genre field, so there's really no way to convert these values and go back to a fixed set of values. The genie is out of the bottle, so to speak. However, this doesn't mean that we can't clarify the genre frame specification to promote the use of multiple genres. The only application that I've found that supports multiple genres is ID3-TagIT. It uses what I think is the simplest, best approach for multiple genres which is simply using a null char delimited list of genre values. In fact, I've adopted its format in my own ID3 library, UltraID3Lib.) This technique has the benefit of being backward compatible with all ID3v2 versions. (Apps should just ignore anything after the first null char delimiter, so they wouldn't fully support the format, but neither would this format break compatibility.) Anyway, not that I want to be such a downer, but I think it's too late to go to a limited set of genre values. There are just too many weird genres out there to ever be codified in a manageable list. Mitchell S. Honnert www.UltraID3Lib.com _____ From: Pat Furrie [mailto:pfurrie at hotmail.com] Sent: Saturday, March 04, 2006 3:31 PM To: id3v2 at id3.org Subject: [ID3 Dev] New genre coding idea? I've been considering how multiple genres can be assigned via ID3. What I do understand: 1) ID3v1 had a single byte which mapped to a fixed and limited list of genres. 2) ID3v2 allows for a genre frame which can have some mix of genres. 3) Very few programs, if any, are using the multiple genre capability. 4) Programs like iTunes seem to allow multiple genres, but in reality users are only creating a new genre which is the composite of existing types. However there is no cross-referencing: I can give an MP3 the "genre" of "rock soundtrack" but if I list everything in the "rock" or "soundtrack" genres, it doesn't show up. Additionally, "soundtrack, rock" is not equivalent to "rock, soundtrack" in the iTunes world. One way of dealing with it is to utilize free-form text with delimiters, allowing users to enter as many of whatever genres they come up with. However, this has a few problems: 1) Because the length of the field is unknown, padding must be used, and the possibility still exists of needing to re-write the rest of the file due to exceeding the space given by any padding. 2) Any spelling errors create additional genres when they shouldn't exist (does "soundtrack" equal "sound track"?) 3) What works for English doesn't work for other languages. Localization is difficult. The original one-byte method in ID3v1 did have the potential of being able to be localized, since the genre name lookup table could be altered for whatever the user's language is. But it only allows a single genre, and it is easy to show that most files (of any type) can be reasonably listed in multiple categories. Another solution is to use the same look-up table, but have multiple delimited values listed. Let's bit-map the genre information. Make the bit-mapped switches correspond to smaller divisions of description as opposed to compounded versions. For example, terms like "Rock," "Classic Rock," "AlternRock," "Instrumental Rock," "Gothic Rock," "Folk-Rock," "Progressive Rock," "Psychedelic Rock," "Southern Rock," "Symphonic Rock," "Hard Rock," "Slow Rock," and "Punk Rock" are replaced by "Rock," "Classic," "Alternate," "Instrumental," "Gothic," "Folk," Progressive," "Psychedelic," "Southern," "Symphonic," "Hard," "Slow," and "Punk." Note that any of those terms can be combined with any of the others to give a larger variety of unique genres (ie, "Instrumental Punk" and "Southern Folk"), as well as with a myriad of other terms condensed from the current list of genres, and a host of additional modifiers and qualifiers. This atomized approach to the subjective art of classification allows for a far more expansive range of control and choice while keeping spellings and terms standardized. And while there are fewer than 150 genres in the more-or-less standard version, this new approach allows for, well. an awfully big number. 2 to the number of bits used in the bit map. After doing some digging up of genre types from the Internet, it seems 1000 bits should be sufficient. This includes a wide range of modifying terms and plenty of reserved space for the future. Doing a little rounding to come up with an even number, 150 bytes appears to be a good number to consider for the size of the reserved space. Bitmap Advantages: - Efficient. With a small amount of file space, a very large number of genres can be described. - Complete. A user can have any combination of a large number of genre and modifiers to describe each audio file. - Language independent. The bits map to terms which can be localized to a user's language. - Can be cross-referenced. Files can easily be sorted on a single genre attribute or any combination. - Changes don't ever affect a file's size. Once the fixed-length bit-map has been attached, regardless of what genre/modifier values have been selected, genre changes will no longer have any impact on file size. - Standardized terms and spellings. A user has a hard enough time entering the same text each time exactly the same, let alone having different users entering textual genre information the same. Consistency in spelling and terms becomes possible when the choices are mapped to a fixed word list. - Room for term growth. The full list of genre switches wouldn't be exhausted, leaving head-room for additional bit-mappable items to be added over time. Bitmap Disadvantages - No user-customized genres. This is the case with the ID3v1 scheme as well. However, the baseline list of proposed genres and modifiers is much more vast, and the freedom for creating any combination gives choices many orders of magnitude greater than before. Also, by having standardized genres, you can be sure that when you import an audio file with this scheme into your own database, the genres will mesh - no ambiguity due to spelling, language, or word order (that is, "soundtrack rock" will equal "rock soundtrack".) - Not "human readable." The genre and modifier data is bit-coded, so if a user were to open such a file with a text viewer/editor, they'd have difficulty making sense of it. However, most users never have the need to, know how to, or want to open audio files with a text editor. They'll use software designed for viewing and editing the tags. Also, coded in hex, this could easily exist with an XML framework, if need be. - Always consumes 150 bytes. From a relative point-of-view, this is a big increase. This is a lot more than the 1 byte for ID3v1. However, from an absolute viewpoint, this isn't much. For a user with ten-thousand MP3s, the total impact byte-wise is 1.5 megs. Using my collection of slightly more than ten-thousand MP3s as an example, it consumes just over forty gigabytes of disk space. 1.5 megs of additional space amounts to a percentage increase of less than 4 one-thousandths of one percent. -------------- Pat -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Thu Mar 2 04:54:10 2006 From: id3v2 at audiott.com (Michal Vician) Date: Thu, 2 Mar 2006 13:54:10 +0100 (CET) Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <200603011436.40269.wheeler@kde.org> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> Message-ID: <1836.213.81.187.20.1141304050.squirrel@213.81.187.20> > For those formats: > > - WAV has no tags > - WMA has its own tagging format, which is specified in the wma spec, > available in the MSDN (which unfortunately, basically does not allow Open > Source implementations) > - Ogg Vorbis uses "Xiph Comments" (same as later versions of FLAC and > Speex), > which are embedded into the Ogg container. You can find information on > these > in the comment and container specs on xiph.org > - AAC uses yet another tagging format, which does not at present have a > published spec Many thanks for replies. Grrr, I can see that the "audio files metadata" situation is not very good. I mean that there are too many specifications and if you want to make an application which would support all of them, it might be very confusing to user. The similar situation is in ID3 - "John Doe" users are confused of ID3 tag versions and don't know which one to use if an application offers/supports all ID3 versions. First I wanted to implement ID3v2 as "widely" as possible. Now my application supports 39 ID3v2 frames and I'm angry that I can't write it to other audio file formats :-( What a pity... I'm curious if there is a way to "translate" all ID3v2 frames (APIC, ...) to "Xiph Comments" etc... If there is no way, I must only admit that my application will never support other format than MP3. Miso > On Wednesday 01 March 2006 13:12, Michal Vician wrote: >> Sorry, I've forgotten to say that I've read the following: >> >> ----- >> ID3.org receives one frequent question in various forms: >> >> * What is the tagging format in my Windows Media File? >> * What is the tagging format in my iTunes file? >> * What is the tagging format in my ogg vorbis file? >> >> Answer? All audio formats can, and most probably do, use the ID3 tag >> format. They do this because the ID3 tag standard is so wide spread and >> implementation libraries are readily available. >> ------ > > This information is incorrect and should be removed from the web site. > ID3v2 > tags will break formats which are container-based such as Ogg Vorbis and > WMA. > >> - Does it mean that I can write an ID3v2 tag to formats like wma, ogg... >> without any doubt? >> - Can I also write ID3v1 tag into this files? >> - Can anybody give me a list of audio file formats, where can I write >> ID3 >> tags? > >> > I would like to implement support to my application also for other >> audio >> > file formats, not only for MP3 (eg. for wav, wma, ogg, aac ...). >> However, >> > I'm not sure if I can write ID3v2 tags to such kind of files in the >> same >> > way like in MP3. Can anybody help me with this, please? > > For those formats: > > - WAV has no tags > - WMA has its own tagging format, which is specified in the wma spec, > available in the MSDN (which unfortunately, basically does not allow Open > Source implementations) > - Ogg Vorbis uses "Xiph Comments" (same as later versions of FLAC and > Speex), > which are embedded into the Ogg container. You can find information on > these > in the comment and container specs on xiph.org > - AAC uses yet another tagging format, which does not at present have a > published spec > > I wrote TagLib specifically for this sort of problem. It currently > supports > MP3s (with ID3v1, ID3v2 or APE tags), Ogg Vorbis, FLAC (with Xiph Comments > or > ID3 tags), and MPC files (with APE tags). The next version will support > AAC > as well. WMA support won't happen unless someone reverse engineers the > format. > > -Scott --------------------------------------------------------------------- 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 3 05:51:09 2006 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 3 Mar 2006 14:51:09 +0100 (CET) Subject: [ID3 Dev] VB6 ID3v2 implementation In-Reply-To: <44084785.3080607@northpb.com> Message-ID: <20060303135110.97305.qmail@web26406.mail.ukl.yahoo.com> --- Dan O'Neill schrieb: > > Send me the links and description or post them to > the list. > > dano > The link to the main page of my mp3 tagger would be www.magic-tagger.com You can get the source code of the ID3 tagging module at the download category there. I could also create a separate site for the ID3 tagging module in order to provide a direct link at id3.org 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 From mitch at honnert.com Sat Mar 4 13:40:01 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 4 Mar 2006 16:40:01 -0500 Subject: [ID3 Dev] New genre coding idea? In-Reply-To: Message-ID: <20060304213958.XATJ4651.gx5.fuse.net@avoca> Pat, it's obvious you put a lot of thought into this proposal, but I think there's a "showstopper" item missing from your Disadvantages list. Converting the existing genre frame to support a bitmap style representation of multiple genres would break backward compatibility. The ID3 standard has had free-form genres for so long, it'd be next to impossible to go back to using a fixed list, even one that allowed for modified pairs like you described. For example, if your proposal were adopted, how should an ID3-compatible program handle the genre of "Venezuelan Beaver Cheese Chill Out Groove" or even "Mitch's Favs". You just never know what people have put in the Genre field, so there's really no way to convert these values and go back to a fixed set of values. The genie is out of the bottle, so to speak. However, this doesn't mean that we can't clarify the genre frame specification to promote the use of multiple genres. The only application that I've found that supports multiple genres is ID3-TagIT. It uses what I think is the simplest, best approach for multiple genres which is simply using a null char delimited list of genre values. In fact, I've adopted its format in my own ID3 library, UltraID3Lib.) This technique has the benefit of being backward compatible with all ID3v2 versions. (Apps should just ignore anything after the first null char delimiter, so they wouldn't fully support the format, but neither would this format break compatibility.) Anyway, not that I want to be such a downer, but I think it's too late to go to a limited set of genre values. There are just too many weird genres out there to ever be codified in a manageable list. Mitchell S. Honnert www.UltraID3Lib.com _____ From: Pat Furrie [mailto:pfurrie at hotmail.com] Sent: Saturday, March 04, 2006 3:31 PM To: id3v2 at id3.org Subject: [ID3 Dev] New genre coding idea? I've been considering how multiple genres can be assigned via ID3. What I do understand: 1) ID3v1 had a single byte which mapped to a fixed and limited list of genres. 2) ID3v2 allows for a genre frame which can have some mix of genres. 3) Very few programs, if any, are using the multiple genre capability. 4) Programs like iTunes seem to allow multiple genres, but in reality users are only creating a new genre which is the composite of existing types. However there is no cross-referencing: I can give an MP3 the "genre" of "rock soundtrack" but if I list everything in the "rock" or "soundtrack" genres, it doesn't show up. Additionally, "soundtrack, rock" is not equivalent to "rock, soundtrack" in the iTunes world. One way of dealing with it is to utilize free-form text with delimiters, allowing users to enter as many of whatever genres they come up with. However, this has a few problems: 1) Because the length of the field is unknown, padding must be used, and the possibility still exists of needing to re-write the rest of the file due to exceeding the space given by any padding. 2) Any spelling errors create additional genres when they shouldn't exist (does "soundtrack" equal "sound track"?) 3) What works for English doesn't work for other languages. Localization is difficult. The original one-byte method in ID3v1 did have the potential of being able to be localized, since the genre name lookup table could be altered for whatever the user's language is. But it only allows a single genre, and it is easy to show that most files (of any type) can be reasonably listed in multiple categories. Another solution is to use the same look-up table, but have multiple delimited values listed. Let's bit-map the genre information. Make the bit-mapped switches correspond to smaller divisions of description as opposed to compounded versions. For example, terms like "Rock," "Classic Rock," "AlternRock," "Instrumental Rock," "Gothic Rock," "Folk-Rock," "Progressive Rock," "Psychedelic Rock," "Southern Rock," "Symphonic Rock," "Hard Rock," "Slow Rock," and "Punk Rock" are replaced by "Rock," "Classic," "Alternate," "Instrumental," "Gothic," "Folk," Progressive," "Psychedelic," "Southern," "Symphonic," "Hard," "Slow," and "Punk." Note that any of those terms can be combined with any of the others to give a larger variety of unique genres (ie, "Instrumental Punk" and "Southern Folk"), as well as with a myriad of other terms condensed from the current list of genres, and a host of additional modifiers and qualifiers. This atomized approach to the subjective art of classification allows for a far more expansive range of control and choice while keeping spellings and terms standardized. And while there are fewer than 150 genres in the more-or-less standard version, this new approach allows for, well. an awfully big number. 2 to the number of bits used in the bit map. After doing some digging up of genre types from the Internet, it seems 1000 bits should be sufficient. This includes a wide range of modifying terms and plenty of reserved space for the future. Doing a little rounding to come up with an even number, 150 bytes appears to be a good number to consider for the size of the reserved space. Bitmap Advantages: - Efficient. With a small amount of file space, a very large number of genres can be described. - Complete. A user can have any combination of a large number of genre and modifiers to describe each audio file. - Language independent. The bits map to terms which can be localized to a user's language. - Can be cross-referenced. Files can easily be sorted on a single genre attribute or any combination. - Changes don't ever affect a file's size. Once the fixed-length bit-map has been attached, regardless of what genre/modifier values have been selected, genre changes will no longer have any impact on file size. - Standardized terms and spellings. A user has a hard enough time entering the same text each time exactly the same, let alone having different users entering textual genre information the same. Consistency in spelling and terms becomes possible when the choices are mapped to a fixed word list. - Room for term growth. The full list of genre switches wouldn't be exhausted, leaving head-room for additional bit-mappable items to be added over time. Bitmap Disadvantages - No user-customized genres. This is the case with the ID3v1 scheme as well. However, the baseline list of proposed genres and modifiers is much more vast, and the freedom for creating any combination gives choices many orders of magnitude greater than before. Also, by having standardized genres, you can be sure that when you import an audio file with this scheme into your own database, the genres will mesh - no ambiguity due to spelling, language, or word order (that is, "soundtrack rock" will equal "rock soundtrack".) - Not "human readable." The genre and modifier data is bit-coded, so if a user were to open such a file with a text viewer/editor, they'd have difficulty making sense of it. However, most users never have the need to, know how to, or want to open audio files with a text editor. They'll use software designed for viewing and editing the tags. Also, coded in hex, this could easily exist with an XML framework, if need be. - Always consumes 150 bytes. From a relative point-of-view, this is a big increase. This is a lot more than the 1 byte for ID3v1. However, from an absolute viewpoint, this isn't much. For a user with ten-thousand MP3s, the total impact byte-wise is 1.5 megs. Using my collection of slightly more than ten-thousand MP3s as an example, it consumes just over forty gigabytes of disk space. 1.5 megs of additional space amounts to a percentage increase of less than 4 one-thousandths of one percent. -------------- Pat -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at northpb.com Fri Mar 3 05:41:25 2006 From: id3v2 at northpb.com (Dan O'Neill) Date: Fri, 03 Mar 2006 05:41:25 -0800 Subject: [ID3 Dev] VB6 ID3v2 implementation In-Reply-To: <20060303133921.82961.qmail@web26403.mail.ukl.yahoo.com> References: <20060303133921.82961.qmail@web26403.mail.ukl.yahoo.com> Message-ID: <44084785.3080607@northpb.com> Mathias Kunter wrote: > My question is now, would it be possible to add my VB6 > tagging library / mp3 tagger to the implementations > page on id3.org in order to share it with other > developers / users? Who can I contact about this? > > Best regards > Mathias Send me the links and description or post them to the list. dano --------------------------------------------------------------------- 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 1 13:02:20 2006 From: wheeler at kde.org (Scott Wheeler) Date: Wed, 1 Mar 2006 22:02:20 +0100 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <1cd7d6da0603011211k42421c6ck@mail.gmail.com> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> <1cd7d6da0603011211k42421c6ck@mail.gmail.com> Message-ID: <200603012202.20361.wheeler@kde.org> On Wednesday 01 March 2006 21:11, Thy Nae wrote: > Hie, > I'm your french translator, do you remenber ? ;-) I think you were actually replying to Michal, but you hit reply to my mail. When you hit reply your mail client generates a header like (from your mail): In-Reply-To: <200603011436.40269.wheeler at kde.org> For those of us that are on dozens of mailing lists and use threaded readers we see something like this: http://developer.kde.org/~wheeler/images/mail-threading.png > I'm actually planning to write ( in python ) an "universal" tagging > library; it will be released as free software under the terms Lgpl licence, > it means you will be able to use it even if ATT is not free/open software. > (Note that I respect your choice but I think that a tool like this will > know more sucess if it was totally free; OK, now I stop proselytism it's > enough ;-) You're of course welcome to write your own, but there are Python bindings for TagLib: http://developer.kde.org/~wheeler/taglib.html#bindings > About the ogg/vorbis tagging , the system is more flexible but less > advanced and normalized, it works with the couple "key"= value , coded in > text at the beginning of the files. > The best point is the possibility to easylie add new keys, the bad one is > that there is no convention about them , even with basic like "artist" , > "title" , "album" and in absence of any superior autority the risk is that > situation become anarchic. There is an informal set of standard comments mentioned here: http://www.xiph.org/vorbis/doc/v-comment.html > Note that an ogg vorbis can be tagged with id3tag, but some crapy softwares > are confused with this , they consider that in id3 taggued file can only be > a mp3 , nothing else , they don't analyze frame to determine that. If you add an ID3 tag to an Ogg Vorbis file (assuming that you don't embed it in the bitstream, which would be possible, but silly) you've just corrupted that file. Software *should not* recognize ID3 tags stuck onto Ogg Vorbis files. Ogg, like AVI or QuickTime, is a container format. Data in Ogg files has to be split into packets / pages and included at the proper place in the Ogg bitstream. You can't just add data to the beginning or end at random the way that you can in MP3 files. -Scott -- I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, "Dijkstra would not have liked this", well that would be enough immortality for me. -E. W. Dijkstra --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From john_schnittker at yahoo.com Sat Mar 25 21:23:19 2006 From: john_schnittker at yahoo.com (John Schnittker) Date: Sat, 25 Mar 2006 21:23:19 -0800 (PST) Subject: [ID3 Dev] Using ID3 Lyrics tags to learn a foreign language In-Reply-To: <441F2377.108@fastmail.fm> Message-ID: <20060326052319.89603.qmail@web30703.mail.mud.yahoo.com> Greetings, The objective is to use audiofiles as tools to learn a foreign language. A typical usecase would be: The learner views the synchronized lyrics, in both foreign and native languages, as the spoken dialogue plays. It would be an irresistable feature for any of the "language-learning" podcasts now proliferating across the web. I wonder if anyone can point me to a guide for tagging song lyrics in multiple languages (ie., inserting SYLT/USLT tags in multiple languages,) preferably on the linux platform, if possible? Visiting the KDE bug reporting site, it appears that developers are considering SYLT and USLT support in Linux taglib: http://bugs.kde.org/show_bug.cgi?id=94927 And eventually, the popular KDE audio player, Amarok, would support SYLT/USLT: http://bugs.kde.org/show_bug.cgi?id=85961 Best, John Schnittker __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From tsorensen at gmail.com Mon Mar 6 05:21:51 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Mon, 6 Mar 2006 08:21:51 -0500 Subject: [ID3 Dev] New genre coding idea? In-Reply-To: References: Message-ID: <4da424620603060521y1345beb7yf9d674e57a71dfce@mail.gmail.com> On 3/4/06, Pat Furrie wrote: > 4) Programs like iTunes seem to allow multiple genres, but in reality > users are only creating a new genre which is the composite of existing > types. However there is no cross-referencing: I can give an MP3 the "genre" > of "rock soundtrack" but if I list everything in the "rock" or "soundtrack" > genres, it doesn't show up. Additionally, "soundtrack, rock" is not > equivalent to "rock, soundtrack" in the iTunes world. Except that you're wrong here. If you want to talk about how iTunes does it, you're correct initially -- if you want to list a song as belonging to both the "rock" and "soundtrack" genres then iTunes simply mashes them together with a space (think ID3V2.4, but with spaces instead of nulls separating the genres). Now if I filter my tracks, inside of iTunes, by genre and I ask for "rock" (or "Rock" or "ROCK" or whatever -- iTunes is case-insensitive) then it *will* list the song I have tagged as "rock soundtrack". If I ask for "soundtrack" then it will list it as well. iTunes does a substring search for matching. And this works for most things. There's a rather limited case where you may want two words to be uniquely joined, or where substring matching may do the Wrong Thing (e.g. -- search for Classic and you get not only "Classical" but also "Classic Rock", which probably don't work together), but they're solvable through the use of regular expressions, quoting, and other methods. > 1) Because the length of the field is unknown, padding must be used, > and the possibility still exists of needing to re-write the rest of the file > due to exceeding the space given by any padding. The ID3V2 standard recommends padding to 2K or 4K. I'm seriously doubting that genres is what's going to cause you to exceed that. > 2) Any spelling errors create additional genres when they shouldn't > exist (does "soundtrack" equal "sound track"?) This is an issue, although it's solvable through a soundex search. > 3) What works for English doesn't work for other languages. > Localization is difficult. This is a false issue. If we're going to concern ourselves over this then we'd better think about how to deal with auto-translating the title, artist, and other textual data to other languages too. They are not necessarily the same, particularly for Asian languages. > Bitmap Disadvantages As pointed out, the biggest disadvantage is that it breaks backwards compatability. You're talking about ID3V3 now, not ID3V2. Genres are endlessly mutable -- new ones are created all the time, even if they're just fusions or twists of existing ones. Trying to hardcode that is an excercise in futility. If you're concerned over pattern matching, then use more loose search methods as suggested above. If you're concerned over I18N, then just start weeping now. This is the least of your worries. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From gruen0aermel at gmail.com Wed Mar 1 15:13:04 2006 From: gruen0aermel at gmail.com (Aaron VonderHaar) Date: Wed, 1 Mar 2006 15:13:04 -0800 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <200603012202.20361.wheeler@kde.org> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> <1cd7d6da0603011211k42421c6ck@mail.gmail.com> <200603012202.20361.wheeler@kde.org> Message-ID: Why not consider ID3 a separate container format, which has the following structure: The "data" could perhaps be an ogg vorbis "file" or wav, mod, aac, midi-- anything, but the file on disk would contain the tag concatenated with the audio data, the same as with tagged mp3 (and flac with id3). Of course for this to work your application would have to be modified recognize the tags and to start decoding audio at the data section, but this would likely be trivial for any application that already supports id3 for mp3 files. This seems like a good way to go, since it makes id3 a metadata layer that's independant of the audio format. --Aaron V. On 01/03/06, Scott Wheeler wrote: > > If you add an ID3 tag to an Ogg Vorbis file (assuming that you don't embed it > in the bitstream, which would be possible, but silly) you've just corrupted > that file. Software *should not* recognize ID3 tags stuck onto Ogg Vorbis > files. > > Ogg, like AVI or QuickTime, is a container format. Data in Ogg files has to > be split into packets / pages and included at the proper place in the Ogg > bitstream. You can't just add data to the beginning or end at random the way > that you can in MP3 files. > > -Scott > > -- > I mean, if 10 years from now, when you are doing something quick and dirty, > you suddenly visualize that I am looking over your shoulders and say to > yourself, "Dijkstra would not have liked this", well that would be enough > immortality for me. > -E. W. Dijkstra > > --------------------------------------------------------------------- > 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 david_wu31 at yahoo.com Mon Mar 6 10:11:28 2006 From: david_wu31 at yahoo.com (danny amaz) Date: Mon, 6 Mar 2006 10:11:28 -0800 (PST) Subject: [ID3 Dev] about MP3 loyalty fee Message-ID: <20060306181128.76472.qmail@web53302.mail.yahoo.com> Does anybody know how to pay MP3 loyalty? Thanks, Denny. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Wed Mar 1 10:54:57 2006 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 01 Mar 2006 10:54:57 -0800 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <200603011436.40269.wheeler@kde.org> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> Message-ID: <4405EE01.4040000@northpb.com> Based on Scott's feedback, updates have been made to these portions of the ID3.org website. Please send me corrections, if any. http://www.id3.org/faq.html See Q: Are ID3 tags only available in MP3 audio format? http://www.id3.org/intro.html See ID3.org receives one frequent question Thanks, dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at audiott.com Wed Mar 1 04:05:05 2006 From: id3v2 at audiott.com (Michal Vician) Date: Wed, 1 Mar 2006 13:05:05 +0100 (CET) Subject: [ID3 Dev] ID3 tag and audio file formats Message-ID: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> I would like to implement support to my application also for other audio file formats, not only for MP3 (eg. for wav, wma, ogg, aac ...). However, I'm not sure if I can write ID3v2 tags to such kind of files in the same way like in MP3. Can anybody help me with this, please? Many thanks Miso --- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- 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 1 16:48:12 2006 From: wheeler at kde.org (Scott Wheeler) Date: Thu, 2 Mar 2006 01:48:12 +0100 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <200603012202.20361.wheeler@kde.org> Message-ID: <200603020148.13016.wheeler@kde.org> On Thursday 02 March 2006 0:13, Aaron VonderHaar wrote: > Why not consider ID3 a separate container format, which has the > following structure: > > > > The "data" could perhaps be an ogg vorbis "file" or wav, mod, aac, > midi-- anything, but the file on disk would contain the tag > concatenated with the audio data, the same as with tagged mp3 (and > flac with id3). > > Of course for this to work your application would have to be modified > recognize the tags and to start decoding audio at the data section, > but this would likely be trivial for any application that already > supports id3 for mp3 files. > > This seems like a good way to go, since it makes id3 a metadata layer > that's independant of the audio format. Well, again, technically this could work, but that has about zero chance of adoption in the real world. There's not going to be mass movement away from traditional media formats to ID3-ified media formats, especially since that would break backwards compatibility with both ID3 and every major media format and well, it's not a terribly sound idea to boot. I kind of get that feeling for a lot of what's said on this list -- technical feasibility and real world practicality are quite separate. It's something similar to the bikeshed (*) phenomenon. There are all sorts of things that would be possible -- coming up with new container formats, defining an ID3v3 that works with XML streams, move to comment value pairs, think of new and exciting ways of mangling relatively small bits of information, but until somebody steps up and says: "I am going to start the draft of a new standard. I have already spoken with Ginormus Software, Inc., Media-monopolies-r-us and Frooty-Computers and they will both support the new standard and help draft it; is anyone else interested in working on the preparation of this document?" Until that point it's all just "What color do we paint the bikeshed?" -Scott (*) http://www.bikeshed.com/ -- Confidence is the feeling you have before you understand the situation. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From thy.nae at gmail.com Wed Mar 1 12:11:05 2006 From: thy.nae at gmail.com (Thy Nae) Date: Wed, 1 Mar 2006 21:11:05 +0100 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <200603011436.40269.wheeler@kde.org> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> <200603011436.40269.wheeler@kde.org> Message-ID: <1cd7d6da0603011211k42421c6ck@mail.gmail.com> Hie, I'm your french translator, do you remenber ? ;-) I'm actually planning to write ( in python ) an "universal" tagging library; it will be released as free software under the terms Lgpl licence, it means you will be able to use it even if ATT is not free/open software. (Note that I respect your choice but I think that a tool like this will know more sucess if it was totally free; OK, now I stop proselytism it's enough ;-) About the ogg/vorbis tagging , the system is more flexible but less advanced and normalized, it works with the couple "key"= value , coded in text at the beginning of the files. The best point is the possibility to easylie add new keys, the bad one is that there is no convention about them , even with basic like "artist" , "title" , "album" and in absence of any superior autority the risk is that situation become anarchic. Note that an ogg vorbis can be tagged with id3tag, but some crapy softwares are confused with this , they consider that in id3 taggued file can only be a mp3 , nothing else , they don't analyze frame to determine that. Don't try to contact me for further information. (and i'm waiting for fedora core 5 who will be able to execute your java code) Cheers. Thy Nae -- "Si vous pensez que les hackers ne sont qu'une bande d'anarchistes pr?te ? tout mettre ? feu et ? sang parceque ?a les amuse , vous vous trompez du tout au tout : nous sommes bien pires que ?a" No One Is Innocent , Nomenklatura -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Wed Mar 1 04:12:18 2006 From: id3v2 at audiott.com (Michal Vician) Date: Wed, 1 Mar 2006 13:12:18 +0100 (CET) Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> Message-ID: <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> Sorry, I've forgotten to say that I've read the following: ----- ID3.org receives one frequent question in various forms: * What is the tagging format in my Windows Media File? * What is the tagging format in my iTunes file? * What is the tagging format in my ogg vorbis file? Answer? All audio formats can, and most probably do, use the ID3 tag format. They do this because the ID3 tag standard is so wide spread and implementation libraries are readily available. ------ - Does it mean that I can write an ID3v2 tag to formats like wma, ogg... without any doubt? - Can I also write ID3v1 tag into this files? - Can anybody give me a list of audio file formats, where can I write ID3 tags? Many, many thanks Miso > I would like to implement support to my application also for other audio > file formats, not only for MP3 (eg. for wav, wma, ogg, aac ...). However, > I'm not sure if I can write ID3v2 tags to such kind of files in the same > way like in MP3. Can anybody help me with this, please? > > Many thanks > Miso --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From pfurrie at hotmail.com Sat Mar 4 12:30:57 2006 From: pfurrie at hotmail.com (Pat Furrie) Date: Sat, 4 Mar 2006 15:30:57 -0500 Subject: [ID3 Dev] New genre coding idea? Message-ID: I?ve been considering how multiple genres can be assigned via ID3. What I do understand: 1) ID3v1 had a single byte which mapped to a fixed and limited list of genres. 2) ID3v2 allows for a genre frame which can have some mix of genres. 3) Very few programs, if any, are using the multiple genre capability. 4) Programs like iTunes seem to allow multiple genres, but in reality users are only creating a new genre which is the composite of existing types. However there is no cross-referencing: I can give an MP3 the ?genre? of ?rock soundtrack? but if I list everything in the ?rock? or ?soundtrack? genres, it doesn?t show up. Additionally, ?soundtrack, rock? is not equivalent to ?rock, soundtrack? in the iTunes world. One way of dealing with it is to utilize free-form text with delimiters, allowing users to enter as many of whatever genres they come up with. However, this has a few problems: 1) Because the length of the field is unknown, padding must be used, and the possibility still exists of needing to re-write the rest of the file due to exceeding the space given by any padding. 2) Any spelling errors create additional genres when they shouldn?t exist (does ?soundtrack? equal ?sound track??) 3) What works for English doesn?t work for other languages. Localization is difficult. The original one-byte method in ID3v1 did have the potential of being able to be localized, since the genre name lookup table could be altered for whatever the user?s language is. But it only allows a single genre, and it is easy to show that most files (of any type) can be reasonably listed in multiple categories. Another solution is to use the same look-up table, but have multiple delimited values listed. Let?s bit-map the genre information. Make the bit-mapped switches correspond to smaller divisions of description as opposed to compounded versions. For example, terms like ?Rock,? ?Classic Rock,? ?AlternRock,? ?Instrumental Rock,? ?Gothic Rock,? ?Folk-Rock,? ?Progressive Rock,? ?Psychedelic Rock,? ?Southern Rock,? ?Symphonic Rock,? ?Hard Rock,? ?Slow Rock,? and ?Punk Rock? are replaced by ?Rock,? ?Classic,? ?Alternate,? ?Instrumental,? ?Gothic,? ?Folk,? Progressive,? ?Psychedelic,? ?Southern,? ?Symphonic,? ?Hard,? ?Slow,? and ?Punk.? Note that any of those terms can be combined with any of the others to give a larger variety of unique genres (ie, ?Instrumental Punk? and ?Southern Folk?), as well as with a myriad of other terms condensed from the current list of genres, and a host of additional modifiers and qualifiers. This atomized approach to the subjective art of classification allows for a far more expansive range of control and choice while keeping spellings and terms standardized. And while there are fewer than 150 genres in the more-or-less standard version, this new approach allows for, well? an awfully big number? 2 to the number of bits used in the bit map. After doing some digging up of genre types from the Internet, it seems 1000 bits should be sufficient. This includes a wide range of modifying terms and plenty of reserved space for the future. Doing a little rounding to come up with an even number, 150 bytes appears to be a good number to consider for the size of the reserved space. Bitmap Advantages: - Efficient. With a small amount of file space, a very large number of genres can be described. - Complete. A user can have any combination of a large number of genre and modifiers to describe each audio file. - Language independent. The bits map to terms which can be localized to a user?s language. - Can be cross-referenced. Files can easily be sorted on a single genre attribute or any combination. - Changes don?t ever affect a file?s size. Once the fixed-length bit-map has been attached, regardless of what genre/modifier values have been selected, genre changes will no longer have any impact on file size. - Standardized terms and spellings. A user has a hard enough time entering the same text each time exactly the same, let alone having different users entering textual genre information the same. Consistency in spelling and terms becomes possible when the choices are mapped to a fixed word list. - Room for term growth. The full list of genre switches wouldn?t be exhausted, leaving head-room for additional bit-mappable items to be added over time. Bitmap Disadvantages - No user-customized genres. This is the case with the ID3v1 scheme as well. However, the baseline list of proposed genres and modifiers is much more vast, and the freedom for creating any combination gives choices many orders of magnitude greater than before. Also, by having standardized genres, you can be sure that when you import an audio file with this scheme into your own database, the genres will mesh ? no ambiguity due to spelling, language, or word order (that is, ?soundtrack rock? will equal ?rock soundtrack?.) - Not ?human readable.? The genre and modifier data is bit-coded, so if a user were to open such a file with a text viewer/editor, they?d have difficulty making sense of it. However, most users never have the need to, know how to, or want to open audio files with a text editor. They?ll use software designed for viewing and editing the tags. Also, coded in hex, this could easily exist with an XML framework, if need be. - Always consumes 150 bytes. From a relative point-of-view, this is a big increase. This is a lot more than the 1 byte for ID3v1. However, from an absolute viewpoint, this isn?t much. For a user with ten-thousand MP3s, the total impact byte-wise is 1.5 megs. Using my collection of slightly more than ten-thousand MP3s as an example, it consumes just over forty gigabytes of disk space. 1.5 megs of additional space amounts to a percentage increase of less than 4 one-thousandths of one percent. -------------- Pat -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathiaskunter at yahoo.de Fri Mar 3 05:39:21 2006 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 3 Mar 2006 14:39:21 +0100 (CET) Subject: [ID3 Dev] VB6 ID3v2 implementation Message-ID: <20060303133921.82961.qmail@web26403.mail.ukl.yahoo.com> Hi all, I've got a question concerning a VB6 implementation of an ID3 tagging module. Although VB6 is a bit dated, I recognized that there is no VB6 tagging library so far available on the ID3v2 implementations site. I've developed a VB6 tagging library which supports all ID3 versions from 1.0 to 2.4. This library is completely open source and is already successfully used in practice by the mp3 tagger I recently released. The library supports all important ID3 frames. My question is now, would it be possible to add my VB6 tagging library / mp3 tagger to the implementations page on id3.org in order to share it with other developers / users? Who can I contact about this? Best regards 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 From wheeler at kde.org Wed Mar 1 05:36:39 2006 From: wheeler at kde.org (Scott Wheeler) Date: Wed, 1 Mar 2006 14:36:39 +0100 Subject: [ID3 Dev] ID3 tag and audio file formats In-Reply-To: <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> References: <3634.213.81.187.20.1141214705.squirrel@213.81.187.20> <3660.213.81.187.20.1141215138.squirrel@213.81.187.20> Message-ID: <200603011436.40269.wheeler@kde.org> On Wednesday 01 March 2006 13:12, Michal Vician wrote: > Sorry, I've forgotten to say that I've read the following: > > ----- > ID3.org receives one frequent question in various forms: > > * What is the tagging format in my Windows Media File? > * What is the tagging format in my iTunes file? > * What is the tagging format in my ogg vorbis file? > > Answer? All audio formats can, and most probably do, use the ID3 tag > format. They do this because the ID3 tag standard is so wide spread and > implementation libraries are readily available. > ------ This information is incorrect and should be removed from the web site. ID3v2 tags will break formats which are container-based such as Ogg Vorbis and WMA. > - Does it mean that I can write an ID3v2 tag to formats like wma, ogg... > without any doubt? > - Can I also write ID3v1 tag into this files? > - Can anybody give me a list of audio file formats, where can I write ID3 > tags? > > I would like to implement support to my application also for other audio > > file formats, not only for MP3 (eg. for wav, wma, ogg, aac ...). However, > > I'm not sure if I can write ID3v2 tags to such kind of files in the same > > way like in MP3. Can anybody help me with this, please? For those formats: - WAV has no tags - WMA has its own tagging format, which is specified in the wma spec, available in the MSDN (which unfortunately, basically does not allow Open Source implementations) - Ogg Vorbis uses "Xiph Comments" (same as later versions of FLAC and Speex), which are embedded into the Ogg container. You can find information on these in the comment and container specs on xiph.org - AAC uses yet another tagging format, which does not at present have a published spec I wrote TagLib specifically for this sort of problem. It currently supports MP3s (with ID3v1, ID3v2 or APE tags), Ogg Vorbis, FLAC (with Xiph Comments or ID3 tags), and MPC files (with APE tags). The next version will support AAC as well. WMA support won't happen unless someone reverse engineers the format. -Scott -- Had this been an actual emergency, we would have fled in terror, and you would not have been informed. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From bam at iis.fraunhofer.de Tue Mar 7 00:59:55 2006 From: bam at iis.fraunhofer.de (Oliver Baum) Date: Tue, 07 Mar 2006 09:59:55 +0100 Subject: [ID3 Dev] about MP3 loyalty fee In-Reply-To: <20060306181128.76472.qmail@web53302.mail.yahoo.com> References: <20060306181128.76472.qmail@web53302.mail.yahoo.com> Message-ID: <440D4B8B.1080304@iis.fraunhofer.de> On 06.03.2006 19:11, danny amaz wrote: > Does anybody know how to pay MP3 loyalty? See ! (seems to be a little OT here...) Regards, Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org