I was looking around how different formats handle multiple genres and preference storage in the ID tag, from what I can see there is no standard (ID3v2 had pretty much all fields defined). So I am thinking of the need to create a standard that is crossformat compatible (if using freename tags - ogg tags + anything using ape2 tags, rules out id3v1).
So I am thinking:
Genre - main genre
Genre1 - sub genre
Genre2 - sub genre
etc...
Preference - string number 1 to 10
Full Version: Create a new Tagging Standard?
I couldn’t agree morethread
I think that all tag methods have problems, we need a new standard/format that will make everybody happy, regardless of the container format.
I think that all tag methods have problems, we need a new standard/format that will make everybody happy, regardless of the container format.
Enlightening discussion, now before ZzZ appears and calls me something 
APE2 is the current popular, item although it has 0 hardware support (I was talking to a DNNA developer about getting Preference ratings on Rio Karma, there are no standards).
So, what I will do - create a APE2 open source reference library (UTF-8) (hopefully that hardware people can take), and define constant field names (don't like the idea of integer codes, id3v2 was a disaster).
The field tags will be split in to a main group (pretty much standard, although there are differences in implementation) - all string:
ARTIST - ie Madonna
TITLE - ie Nothing Really Matters
ALBUM - ie Ray of Light
YEAR - ie 1992
TRACK - ie 5
GENRE - ie Pop
COMMENT - anyold waffle
as well as others such as:
GENRE1 - ie Dance
PREFERENCE - ie 7
keep them coming - not sure about graphic data - perhaps a specification for PNG encoded as COVERART...
APE2 is the current popular, item although it has 0 hardware support (I was talking to a DNNA developer about getting Preference ratings on Rio Karma, there are no standards).
So, what I will do - create a APE2 open source reference library (UTF-8) (hopefully that hardware people can take), and define constant field names (don't like the idea of integer codes, id3v2 was a disaster).
The field tags will be split in to a main group (pretty much standard, although there are differences in implementation) - all string:
ARTIST - ie Madonna
TITLE - ie Nothing Really Matters
ALBUM - ie Ray of Light
YEAR - ie 1992
TRACK - ie 5
GENRE - ie Pop
COMMENT - anyold waffle
as well as others such as:
GENRE1 - ie Dance
PREFERENCE - ie 7
keep them coming - not sure about graphic data - perhaps a specification for PNG encoded as COVERART...
QUOTE(spoon @ Dec 17 2003, 04:38 PM)
So, what I will do - create a APE2 open source reference library (UTF-8) (hopefully that hardware people can take), and define constant field names (don't like the idea of integer codes, id3v2 was a disaster).
You might also want to have a look at the APEv2 specification. There's already a list of specified field names.
edit: regarding cover-data, please don't forget:
QUOTE
Size should be normally in the range of 1 KByte, NEVER more than 8 KByte. Larger external data should be stored externally using link entries
~ Florian
QUOTE(jtclipper @ Dec 17 2003, 02:59 PM)
I couldn’t agree morethread
I think that all tag methods have problems, we need a new standard/format that will make everybody happy, regardless of the container format.
I think that all tag methods have problems, we need a new standard/format that will make everybody happy, regardless of the container format.
Ah yes, let's break every container format there is. Instead of using tag formats specifically designed for each container (so that they can be read on every possible parser that supports that container).
Menno
QUOTE
from what I can see there is no standard
Nail on the head
I could probably write quite a bit on the frustration I've had on tagging material. Just some of the stuff I've downloaded you can tell instantly someone with no clue about audio quality rips a CD, then labels them 'song - artist' with no tags whatsoever, and a lot of time the labels are incorrect or misspelled, add to the fact that usually you can get several versions of the same song and that information is lost in the label. Some people do put a little more effort and download the basic information from CDDB or FreeDB, however they don't bother verifiying the spelling (personally I think FreeDB should standardize their naming/capitalization scheme to eliminate so many of the duplicate entries) and lack of certain information like year or track #, which for people like me who like to label things with track #s & years, means that I have to go back and do the same work to find this information.
Because there is no standard most people will save the information in default program settings so a lot of tags get saved in ID3v1, which was great at the time, but obviously now there are far better alternatives.
I think creating some sort of standard would do a lot to bring some sort of order to choas.
I should really think what is needed but I was thinking on a basic level a database which would have maybe track databases which would the basic information about the track that could be saved seperatly & within the track and that could be written to any other tag format?
From what I can tell that standard is not being followed (it says Track for tracknumber, but it says store using an INT rather than string).
Plus multiple genres are stored within a list ( ? \r seperating), good pointer though - plenty of names there.
what about the storage of something relating to the CD it came from? freedb, Audio CD TOC, cue sheet (if only for one track, so it can be identified online without sound finger printing)?
Plus multiple genres are stored within a list ( ? \r seperating), good pointer though - plenty of names there.
what about the storage of something relating to the CD it came from? freedb, Audio CD TOC, cue sheet (if only for one track, so it can be identified online without sound finger printing)?
QUOTE(menno @ Dec 17 2003, 03:03 PM)
Ah yes, let's break every container format there is. Instead of using tag formats specifically designed for each container (so that they can be read on every possible parser that supports that container).
Not suggesting breaking anything out there, if mp4 has a built in container format that is fine, I wouldn't dream of appending APE2 to the back of mp4. This is a standard for the tagging formats that can have any field values - Mp3 (with ape2), Ogg, FLAC, Wavepack, MPC they need a direction and reference code.
There is a reference, which was posted earlier. Other fields can be created as needed and might also become widely used (e.g. ALBUM ARTIST). I don't see the need for any more standardization.
dev0
dev0
I followed APEv2 tag specs to the letter in my supporting all proposed fields soft but I think they a hugely incomplete, and about binary data it is just a suggestion of the guy who wrote the specs if a user wants to store a 10 k image it is his choice.
I think that ID3v2 fixed codes is not a real disaster because they force developers to use the same field name for the same purpose but anything is fine with me descriptive fields or short coded fieldnames. I also like the ID3v2 extended fields they are quite useful for especially for the IPLS and APIC frames.
I think fields like tempo, quality, rating, situation, mood are a must if you have a huge collection. I also like lyrics for some of my songs
I really like the idea to extend APEv2 tags thus redefining the standard, APEv2 is fast, smart and easy to implement by software developers, it could use a bit of small corrections ( especially the usage of flags is not very nice too many bits for every field that just have no meaning , if they are reserved for something I do not know what )
I think that ID3v2 fixed codes is not a real disaster because they force developers to use the same field name for the same purpose but anything is fine with me descriptive fields or short coded fieldnames. I also like the ID3v2 extended fields they are quite useful for especially for the IPLS and APIC frames.
I think fields like tempo, quality, rating, situation, mood are a must if you have a huge collection. I also like lyrics for some of my songs
I really like the idea to extend APEv2 tags thus redefining the standard, APEv2 is fast, smart and easy to implement by software developers, it could use a bit of small corrections ( especially the usage of flags is not very nice too many bits for every field that just have no meaning , if they are reserved for something I do not know what )
QUOTE(spoon @ Dec 17 2003, 05:13 PM)
QUOTE(menno @ Dec 17 2003, 03:03 PM)
Ah yes, let's break every container format there is. Instead of using tag formats specifically designed for each container (so that they can be read on every possible parser that supports that container).
Not suggesting breaking anything out there, if mp4 has a built in container format that is fine, I wouldn't dream of appending APE2 to the back of mp4. This is a standard for the tagging formats that can have any field values - Mp3 (with ape2), Ogg, FLAC, Wavepack, MPC they need a direction and reference code.
Ogg Vorbis and FLAC have their own tagging format - Vorbis Comments. You'll break these files too.
~ Florian
If you feel like adding empo, quality, rating, situation or mood to your collection, please do so. No need to create some kind of pseudo standard before. If it's useful people will implement it.
I really think it is time to throw away that Artist - Title
There are constant problems of Various Artists - Track title, which will have no identification of performer.
Even in ID3v2 I don't think they have a performer as a standard listing, they have 'Original artist', 'Composer' both of which could be different.
Maybe you should propose a standard and ask people to comment and give suggestions on what should be added.
For me this 'Artist' field works when you talk one person, for ex I was tagging a live-aid track a little while ago, which included people like bruce springsteen, peter gabrial, tracy chapman, et al. Now I guess that should have been the imfamous 'Various Artists' but the only place to put those performers would be in the comment line so that you could see it in the ID3v1 tags, which of course by the time you hit 30characters you've lost half the performers!
Things to consider - you only get one chance to design the standard so try to design it so that it satisfies as many needs as possible
There are constant problems of Various Artists - Track title, which will have no identification of performer.
Even in ID3v2 I don't think they have a performer as a standard listing, they have 'Original artist', 'Composer' both of which could be different.
Maybe you should propose a standard and ask people to comment and give suggestions on what should be added.
For me this 'Artist' field works when you talk one person, for ex I was tagging a live-aid track a little while ago, which included people like bruce springsteen, peter gabrial, tracy chapman, et al. Now I guess that should have been the imfamous 'Various Artists' but the only place to put those performers would be in the comment line so that you could see it in the ID3v1 tags, which of course by the time you hit 30characters you've lost half the performers!
Things to consider - you only get one chance to design the standard so try to design it so that it satisfies as many needs as possible
QUOTE(dev0 @ Dec 17 2003, 03:17 PM)
There is a reference, which was posted earlier. Other fields can be created as needed and might also become widely used (e.g. ALBUM ARTIST). I don't see the need for any more standardization.
dev0
dev0
There might be a reference, but my original post was to extend the reference (Preferrence, CD Ident etc). Lets talk about a standard for album covers, Cue sheet implementation.
QUOTE
There might be a reference, but my original post was to extend the reference (Preference, CD Indent etc). Lets talk about a standard for album covers, Cue sheet implementation.
I do understand and hoping I am not the only one lets try to lay out some fields.
About CD reference I want to inform you that Media player 9 stores that info along with all music ID's inside ID3v2 PRIV frames thus making impossible for other software to follow that and that pisses me of
so hell yeah lets create a standardized array of fields and their usage.
QUOTE(ganymed @ Dec 17 2003, 03:19 PM)
Ogg Vorbis and FLAC have their own tagging format - Vorbis Comments. You'll break these files too.
Not talking about the format (atleast in the sense of Ogg and Flac), just naming conventions.
Ogg is a perfect exampple where Description was used instead of a standard 'Comment' and off the top of my head 'Tracknumber' instead of track.
You know my goal is I have Preference set on Monkey Files and when I trasfer them to a Rio Karma (in FLAC) the preference goes over - because there is a standard. The only way Apple walk away with the iPod is because they do all this on their own.
Now for people who don't use iTunes, iPod and M4a - lets get some standards so the rest (as in Monkeys, Ogg, FLAC, Mpc, etc) can enjoy those same things.
I would really LOVE a "Rating 1-5" field in tags. If this was implemented, all players could be made to read them. This is especially good for Music Library applications (iTunes, WMP, Media Monkey, Winamp Media Library, MusicMatch and a alot of others). So you could transfer the songs between those apps and still keep the rating that you have given each track.
That would seriously make my day!
That would seriously make my day!
Ogg and FLAC, as mentioned, has their own tagging system. Appending any other type of garbage will be violating the specs.
AFAIK ape2 tags is in the specs of MPC though I could be wrong.
WavPack and MP3 does AFAIK not have a tagging system defined though you can wrap MP3 in MP4 to get a standard file.
So which files do you want to append these new tags to? Or is this just an attempt to tell people which keys (tag items in lack of a better word) that they should use for which info? In which case I would like to know how you dream of making people follow your directions...
I really fail to understand what you want to accomplish; what the real problem is.
AFAIK ape2 tags is in the specs of MPC though I could be wrong.
WavPack and MP3 does AFAIK not have a tagging system defined though you can wrap MP3 in MP4 to get a standard file.
So which files do you want to append these new tags to? Or is this just an attempt to tell people which keys (tag items in lack of a better word) that they should use for which info? In which case I would like to know how you dream of making people follow your directions...
I really fail to understand what you want to accomplish; what the real problem is.
QUOTE(Jan S. @ Dec 17 2003, 03:44 PM)
Or is this just an attempt to tell people which keys (tag items in lack of a better word) that they should use for which info?
That is the one, a set of standard keys (for new items) ** for adding new advanced items to tags. An example of bumbling into something was when Ogg hit the scene and had incompatibilites (thinking more than single format), with a little thought future occurances of this can be avoided.
People will follow it if there is an advantage, if it is future proof, if it works with most players.
** Not suggesting that Tracknumber, description be changed in ogg, it is that, it will remain to be that.
QUOTE
I really lack to understand what you want to accomplish; what the real problem is.
Simple example I use a program to tag ogg/flac files and I use the comment field and then I use winamp to play the files the description field is used thus making a user confused.
Spoon - sorry to post this, it is actually a text file I usually include with my rips - it is a work-in-progress so by no means should be considered as complete but thought it might give you some ideas
QUOTE
Album :
Artist(s) :
Principal Artist(s) :
Instrument(s) and/or Vocals :
Supporting Artist(s) :
Instrument(s) and/or Vocals :
Note: The Album name as well as the artist(s) name should be considered more accurate than those used in the actual encoded files, log files or in the cue sheet. The reason is the same as explained for the track titles below.
Genre :
Subgenre/Styles :
Source Format : CD
CD Process type (AAD/ADD/DDD) :
Type of Recording :
Date of Recording :
Place of Recording :
Recording by :
Commentary by :
Place of Editing and/or
Mastering :
Date of Initial Release :
Date of Version Release :
Language(s) :
Executive Producer(s) :
Producer(s) :
Co-Producer(s) :
Associate Producer(s) :
Arranger(s) :
Publisher :
Parent Company of Publisher :
Catalogue Number :
Manufacturer :
Distributor :
Copyright Holder(s) :
Country of CD Pressing or
Purchase :
UPC :
URL(s) of Publishers,
Distributers or similar :
URL(s) of artist or related :
Ripper : Siq
Tagger : Siq
Supplier :
Grabber : Exact Audio Copy v0.95 pb3
Output Format : CD Image and Cue Sheet (.ape, .cue)
Encoder Format (Lossless/Lossy) : Lossless
Encoder : Monkey's Audio v3.98 a1
Encoder Command Line Options : -c3000
Bitrate (vbr/abr) : N/A
Sample Rate (Hz) : 44,100
Reader : Plextor UltraPlex Wide (PX-40TSUW)
Mode :
Normalization : No
Size : MB
Date of Encoding : June 17, 2003
Encoding Notes
Use of wapet (http://www.ca5e.tk/) in order to apply apev2 tags to CD Image
Wapet is passed the following command line;
%d -t "Artist=%a" -t "Title=%g" -t "Album=%g" -t "Year=%y" -t "Genre=%m" -t "Comment=EAC v0.95 pb3 - Monkey's Audio v3.98 a1" mac.exe %s %d -c3000
Transcoding : Not done
Cover(s) Included : Yes (CD)
Cover(s) source : Scanned from CD case
Tags : APE v2.0
Tagger : Wapet
Lyrics (Partial/Complete) : No
Lyrics Source :
m3u : No
Additional Information Sources :
Post-processing
MP3Gain processing : No
Note: These track titles should be considered more accurate than those used in the actual encoded files, log files or in the cue sheet. For certain operating systems and online databases some characters which may occur in the real track title may not be permissable as part of a file name in the operating system or online database. For this reason the track titles are copied as accurately as possible from the original with the exception of capitalization of words.
Note: Sometimes the album name, artist, or track title may be entered as an alternative in a different language - In these instances the alternative name will generally be separated by /. The preference of order is; 1 - The most commonly used album name, artist name, or track title. 2 - The English album name, artist name, or track title. This information will only be presented in this file to provide as much detail about the album as possible, This information is not displayed in the file names.
Note: As a general policy the following character transformations are done since they are illegal characters in the Windows operating system;
/ -> ,
: -> ;
As stated you may check the actual album name, artist, or track title in this document.
Number of Tracks :
Total Playtime (h:m:s.m) [0:33:41.46]
Artist(s) :
Principal Artist(s) :
Instrument(s) and/or Vocals :
Supporting Artist(s) :
Instrument(s) and/or Vocals :
Note: The Album name as well as the artist(s) name should be considered more accurate than those used in the actual encoded files, log files or in the cue sheet. The reason is the same as explained for the track titles below.
Genre :
Subgenre/Styles :
Source Format : CD
CD Process type (AAD/ADD/DDD) :
Type of Recording :
Date of Recording :
Place of Recording :
Recording by :
Commentary by :
Place of Editing and/or
Mastering :
Date of Initial Release :
Date of Version Release :
Language(s) :
Executive Producer(s) :
Producer(s) :
Co-Producer(s) :
Associate Producer(s) :
Arranger(s) :
Publisher :
Parent Company of Publisher :
Catalogue Number :
Manufacturer :
Distributor :
Copyright Holder(s) :
Country of CD Pressing or
Purchase :
UPC :
URL(s) of Publishers,
Distributers or similar :
URL(s) of artist or related :
Ripper : Siq
Tagger : Siq
Supplier :
Grabber : Exact Audio Copy v0.95 pb3
Output Format : CD Image and Cue Sheet (.ape, .cue)
Encoder Format (Lossless/Lossy) : Lossless
Encoder : Monkey's Audio v3.98 a1
Encoder Command Line Options : -c3000
Bitrate (vbr/abr) : N/A
Sample Rate (Hz) : 44,100
Reader : Plextor UltraPlex Wide (PX-40TSUW)
Mode :
Normalization : No
Size : MB
Date of Encoding : June 17, 2003
Encoding Notes
Use of wapet (http://www.ca5e.tk/) in order to apply apev2 tags to CD Image
Wapet is passed the following command line;
%d -t "Artist=%a" -t "Title=%g" -t "Album=%g" -t "Year=%y" -t "Genre=%m" -t "Comment=EAC v0.95 pb3 - Monkey's Audio v3.98 a1" mac.exe %s %d -c3000
Transcoding : Not done
Cover(s) Included : Yes (CD)
Cover(s) source : Scanned from CD case
Tags : APE v2.0
Tagger : Wapet
Lyrics (Partial/Complete) : No
Lyrics Source :
m3u : No
Additional Information Sources :
Post-processing
MP3Gain processing : No
Note: These track titles should be considered more accurate than those used in the actual encoded files, log files or in the cue sheet. For certain operating systems and online databases some characters which may occur in the real track title may not be permissable as part of a file name in the operating system or online database. For this reason the track titles are copied as accurately as possible from the original with the exception of capitalization of words.
Note: Sometimes the album name, artist, or track title may be entered as an alternative in a different language - In these instances the alternative name will generally be separated by /. The preference of order is; 1 - The most commonly used album name, artist name, or track title. 2 - The English album name, artist name, or track title. This information will only be presented in this file to provide as much detail about the album as possible, This information is not displayed in the file names.
Note: As a general policy the following character transformations are done since they are illegal characters in the Windows operating system;
/ -> ,
: -> ;
As stated you may check the actual album name, artist, or track title in this document.
Number of Tracks :
Total Playtime (h:m:s.m) [0:33:41.46]
Funny, just gave me an idea - how about a Source tag?
ie Rip a file (to FLAC) Source = 'CD'
Convert from FLAC to Mp3 Source = 'FLAC'
ie Rip a file (to FLAC) Source = 'CD'
Convert from FLAC to Mp3 Source = 'FLAC'
Source is great but (the much hated) ID3v2 already has this as Media type.
I strongly beleive that for standard fields ID3v2 must be examined first and those fields be used and after that we could extend it with more fields, like the one's I proposed that make library usage much better.
I strongly beleive that for standard fields ID3v2 must be examined first and those fields be used and after that we could extend it with more fields, like the one's I proposed that make library usage much better.
Hi,
needless to say we would be VERY interested in this. Our current tagging system seems to have some very nice features and is well defined and standardized, but all devs complain its pretty complicated to support in real code
.....
As nobody is really using it AFAIK, now is the right time to adapt a new, open standard IMHO.
needless to say we would be VERY interested in this. Our current tagging system seems to have some very nice features and is well defined and standardized, but all devs complain its pretty complicated to support in real code
.....As nobody is really using it AFAIK, now is the right time to adapt a new, open standard IMHO.
QUOTE
I would really LOVE a "Rating 1-5" field in tags. If this was implemented, all players could be made to read them.
I'd rather prefer to be able to tell programs which tags I want to be used for such special purposes instead of being forced to use pre-defined identifiers. Your way leads to a wrong direction, why should users be forced to use field names they dislike just because of limited tag processing abilities in most current audio players? These programs would have to be altered anyway if you introduce fields like "rating", wouldn't it be a better idea to improve their tagging support?
Strangely, I posted a question along these same ideas in a thread here just last week and got no real response.
As far as tagging standards go, you have MPEG-7, AAF (a partial implementation of MPEG-7), ASF tags (by MS), and ID3v2/1 (v2 is indeed a standard, just poorly implemented and not created by the MPEG group).
MPEG-7 has much to fine a resolution to be convenient for regular consumers. License fees may also apply. Also, I'm not sure that its been finalized yet.
AAF is less granule, but has something like 1600 tags. (maybe more now that its been finalized) License fees may also apply.
ASF tags are what is used in ASF/WMV to hold media information. Information available here, here, here, and here.
ID3v2 is a pretty good standard with the one exception that more than one type of data can be held in a single field. This means that two partial implementations can't read each other's data for the same field. The specs are of course here.
For a synopsis of my conclusions about these formats, feel free to read here.
If anyone is interested, a compilation of almost all tags tags more major formats are available here.
As far as tagging standards go, you have MPEG-7, AAF (a partial implementation of MPEG-7), ASF tags (by MS), and ID3v2/1 (v2 is indeed a standard, just poorly implemented and not created by the MPEG group).
MPEG-7 has much to fine a resolution to be convenient for regular consumers. License fees may also apply. Also, I'm not sure that its been finalized yet.
AAF is less granule, but has something like 1600 tags. (maybe more now that its been finalized) License fees may also apply.
ASF tags are what is used in ASF/WMV to hold media information. Information available here, here, here, and here.
ID3v2 is a pretty good standard with the one exception that more than one type of data can be held in a single field. This means that two partial implementations can't read each other's data for the same field. The specs are of course here.
For a synopsis of my conclusions about these formats, feel free to read here.
If anyone is interested, a compilation of almost all tags tags more major formats are available here.
I checked out the XL file and it presents my opinion in a very complete way...
Why do we have so many formats and why some implement more fields than others to store tag info for the same purpose ?
Why do not need a complicated method to tag our files instead of a nicely defined and smart standard powerful yet easy to implement , with rigid standards yet flexible and user friendly.
So where do we go from here? stay like that or evolve?
Why do we have so many formats and why some implement more fields than others to store tag info for the same purpose ?
Why do not need a complicated method to tag our files instead of a nicely defined and smart standard powerful yet easy to implement , with rigid standards yet flexible and user friendly.
So where do we go from here? stay like that or evolve?
QUOTE(jtclipper @ Dec 17 2003, 01:52 PM)
a nicely defined and smart standard powerful yet easy to implement , with rigid standards yet flexible and user friendly.
What an amazing sentence. You must work in marketing.
The problem is that there are always tradeoffs on either side. By its nature, if you make something more rigid, it becomes less flexible. For instance, in the Matroska system the decision was made to make the tags more on the rigid side to prevent people from goofing them up. There are certainly points where it is very flexible, but it takes a long time to find a balance of where the right spot is. Also, there will always be people that want it more on one side or the other.
For example, if you follow the link in the thread that I pointed to, you will see a discussion on redesigning the Matroska tags system. Some coders find the current system to complex and want to simplify it. The simplified version is still more complex than the Ogg comments version of 'Title=Whatever', but it is less complex than the current system. It would also remove the ability to do nested attributes that the current system allowed. I was really hoping someone from HA/fb2k/AA(AudiophilesAnonymous) would post some comments about it, but apparently no one was THAT interested.
Matroska IS an open standard that anyone can use. The specs are being defined into an entire system, but anyone can use any part of it for their own purposes. So if you want an open Tagging system, perhaps completing the Matroska tags is the answer.
QUOTE(spoon @ Dec 17 2003, 07:23 AM)
There might be a reference, but my original post was to extend the reference (Preferrence, CD Ident etc). Lets talk about a standard for album covers, Cue sheet implementation.
There's already a great standard for album/cover art. Stick all your audio files into an archive, add the cover art to the archive. Zero redundancy. It's what I see all the time downloading albums from P2Ps.
Really, adding cover art (which is an album level datum) to every single file on the album is ludicrous and idiotic. Say you have 30 odd files, with 500kb of cover art total, that's 15MB of cover art over all those 30 files. How stupid is that?
If APEv2 isn't robust enough (and I fully agree that we need to specify a few more fields by standard, like ALBUM ARTIST), there are other solutions available, as Pamel listed. But there aren't many instances where APEv2 won't suffice.
My opinion: Keep cover art out of tags, that's not where they belong. There should be one instance of the cover art, at the album level.
It would be nice to see some nice, simple encapsulation file format that would let you store all the media files in an album in a nice, orderly manner. The problem with ordinary archives are that they take a lot of time to change or update a file inside of them.
QUOTE(Canar @ Dec 17 2003, 04:06 PM)
It would be nice to see some nice, simple encapsulation file format that would let you store all the media files in an album in a nice, orderly manner.
Matroska allows both chapters and tracks in a single file. That means that you can have a single long audio stream with chapters to divide the songs. Or, you could have several seperately encoded songs in different tracks. (Even using different compression formats if you like.) And, it supports attachments so you could attach some cover art and the CUE sheet to recreate the original CD later if you wanted.
Since Matroska keeps popping up, I'd like to add my 2¢:
So does QuickTime
So does QuickTime
QUOTE(Pamel @ Dec 17 2003, 04:21 PM)
Matroska allows both chapters and tracks in a single file. That means that you can have a single long audio stream with chapters to divide the songs. Or, you could have several seperately encoded songs in different tracks. (Even using different compression formats if you like.) And, it supports attachments so you could attach some cover art and the CUE sheet to recreate the original CD later if you wanted.
Well, then, go Matroska!
*waits for a foobar2000 Matroska implementation patiently*
Matroska devs: foobar2000 can likely utilize all the features of a matroska audio stream. I'd love to see a component made for Matroska reading. You'd be able to impress quite a wide variety of people using fb2k's back-end power.
I havent seen it mentioned but there should be support for multiple artist fields. That way when A and B work togther you have:
Artist 1: A
Artist 2: B
NOT
Artist(s): A and B
So when you want to listent to something by A you can find even things that A worked on. Currently you would sorrt by "A and B" because they are linked together and the dumb tags think they are one entity when they are 2 or more.
There should also be support for multiple preferences, that way when multiple ppl use the library they can have there set of preferences. Or when ppl are listening at the same time the average of all of their preferences could be used.
Artist 1: A
Artist 2: B
NOT
Artist(s): A and B
So when you want to listent to something by A you can find even things that A worked on. Currently you would sorrt by "A and B" because they are linked together and the dumb tags think they are one entity when they are 2 or more.
There should also be support for multiple preferences, that way when multiple ppl use the library they can have there set of preferences. Or when ppl are listening at the same time the average of all of their preferences could be used.
@Canar:
This has been discussed by the Matroska devs previously, that is pretty much how they all feel. fb2k is an optimal environment to take advantage of these features. Unfortunately none of the Matroska devs know anything about programming fb2k services. If any fb2k devs could help out, the library is free, as is everything else about the format. And there is always someone in the in the IRC channel to answer questions about the format.
@Eli:
This was already done in the original Matroska tags. You could even specify an email, URL and address for each artist. There is currently some serious discussion about reworking the tagging system in the Matroska.Devel Mailing List. But, keeping the ability to have things like multiple artists, each with their own information, is of the top importance.
This has been discussed by the Matroska devs previously, that is pretty much how they all feel. fb2k is an optimal environment to take advantage of these features. Unfortunately none of the Matroska devs know anything about programming fb2k services. If any fb2k devs could help out, the library is free, as is everything else about the format. And there is always someone in the in the IRC channel to answer questions about the format.
@Eli:
This was already done in the original Matroska tags. You could even specify an email, URL and address for each artist. There is currently some serious discussion about reworking the tagging system in the Matroska.Devel Mailing List. But, keeping the ability to have things like multiple artists, each with their own information, is of the top importance.
Vorbis comments & APEv2 tags support and even encourage the usage of the same field name multiple times, ARTIST is a good example.
Now the 'problem' to solve is that we need an easy way to have this information manipulated in a way that allows us to : Rename files based on ARTIST info,Filter/sort files by ARTIST,Easilly edit the tag.
About cover art inside files or links to cover art ( or any other meta info ) it really is up to the user to decide.
From what i have seen trough the years there is (I think) only one software that supports links to images for the APIC ID3v2 frame,all others support the embedding of the file, so in spite of the standard allowing links practically no one uses them. People will say that image data inside an audio file is wrong and they are right others might say that links are easily broken and they are also right. Both should be available in a tag format.
Now the 'problem' to solve is that we need an easy way to have this information manipulated in a way that allows us to : Rename files based on ARTIST info,Filter/sort files by ARTIST,Easilly edit the tag.
About cover art inside files or links to cover art ( or any other meta info ) it really is up to the user to decide.
From what i have seen trough the years there is (I think) only one software that supports links to images for the APIC ID3v2 frame,all others support the embedding of the file, so in spite of the standard allowing links practically no one uses them. People will say that image data inside an audio file is wrong and they are right others might say that links are easily broken and they are also right. Both should be available in a tag format.
Thinking realistically, as much as it is an uphill struggle just to get a Rating label standard across formats, pushing the Matroska standard is an even more uphill battle.
I like the idea of Multiple Artists, sticking to the existing multi genre standard from APEv2 (that no one uses?), multi-artists can be seperated by \r
All I need to do is to convince the Ogg and FLAC guys this is a good idea, also the Rio guys (to implement APE2) and a few other hardware people.
I like the idea of Multiple Artists, sticking to the existing multi genre standard from APEv2 (that no one uses?), multi-artists can be seperated by \r
All I need to do is to convince the Ogg and FLAC guys this is a good idea, also the Rio guys (to implement APE2) and a few other hardware people.
Well maybe I am wrong but I think the matroska tag is more like movie oriented.
I think that audio and movie tags should remain separated and apart from each other.
Multi genre's are a thing I use a lot, it makes classification and retrieval of files a lot better.
I think a genre/sub-genre/style format is quite convenient.
I think that audio and movie tags should remain separated and apart from each other.
Multi genre's are a thing I use a lot, it makes classification and retrieval of files a lot better.
I think a genre/sub-genre/style format is quite convenient.
QUOTE(spoon @ Dec 18 2003, 06:48 AM)
Thinking realistically, as much as it is an uphill struggle just to get a Rating label standard across formats, pushing the Matroska standard is an even more uphill battle.
I think you misunderstood Pamel (or maybe I misuntderstood you ), what he means (AFAIK) is that the Matroska tagging specs can be taken and used as you want with any other format, as a template to a new spec or whatever, because it's open.QUOTE(jtclipper @ Dec 18 2003, 07:32 AM)
Well maybe I am wrong but I think the matroska tag is more like movie oriented.
In fact they're an amalgamation of all known tags, so they have basically any tag defined elsewhere. Again, as the spec is open you can take only a part of it.
For my $0.02 I think the problem here is that we are talking distributed tagging systems, in essence 1 person - 1 tagging system, which is perhaps why we have a dozen or so formats.
The problems I see is that
1) People don't tag - Probably the worst bunch because if that file is shared then any details about that track are lost
Reason: many don't know about tags, or don't care
Result: If you try and tag the file you could mis-tag it and share it again - then you end up with places like kazaa
2) People who do Partial tagging - Although better than non-taggers - it seems many people tag in a particular manner - ie only ID3v1 tags and hense sometimes important track information is lost, some people like putting artist - track title in the track title field if it is a Various Artists album - why should artist information be in the track title box? I understand that it is important information but that is one of the limits of current ID3 formats.
3) Hardware vendors are not going to support any tagging system until the community demonstarates that it is a standard that has been accepted for some time
The solution I think is in developping a FreeDB-Tag system, where along with a regulated format for tag information, where a database could be kept on each track and perhaps integrate that with one of the more developped tagging systems or create a new one. It would also be nice to integrate technology like musicbrainz uses to identify tracks.
Some ideas
The problems I see is that
1) People don't tag - Probably the worst bunch because if that file is shared then any details about that track are lost
Reason: many don't know about tags, or don't care
Result: If you try and tag the file you could mis-tag it and share it again - then you end up with places like kazaa
2) People who do Partial tagging - Although better than non-taggers - it seems many people tag in a particular manner - ie only ID3v1 tags and hense sometimes important track information is lost, some people like putting artist - track title in the track title field if it is a Various Artists album - why should artist information be in the track title box? I understand that it is important information but that is one of the limits of current ID3 formats.
3) Hardware vendors are not going to support any tagging system until the community demonstarates that it is a standard that has been accepted for some time
The solution I think is in developping a FreeDB-Tag system, where along with a regulated format for tag information, where a database could be kept on each track and perhaps integrate that with one of the more developped tagging systems or create a new one. It would also be nice to integrate technology like musicbrainz uses to identify tracks.
Some ideas
QUOTE(jtclipper @ Dec 18 2003, 07:32 AM)
Well maybe I am wrong but I think the matroska tag is more like movie oriented.
I think that audio and movie tags should remain separated and apart from each other.
Multi genre's are a thing I use a lot, it makes classification and retrieval of files a lot better.
I think a genre/sub-genre/style format is quite convenient.
I think that audio and movie tags should remain separated and apart from each other.
Multi genre's are a thing I use a lot, it makes classification and retrieval of files a lot better.
I think a genre/sub-genre/style format is quite convenient.
Outlyer hit most of the points on this, but I thought I would just add a little more, so if you're content with what he said, then skip it.
First, if you look at the excel spreadsheet I linked to you will notice that there are hardly any movie specific tags. This is because there just isn't much in the way of normal movie tagging systems out there. You have the AVI extended set, and that is it.
Second, other than a handful of movie specific tags, they share all other tags. There just isn't a reason to needlessly increase the number of tags everyone needs to support.
Third, same as the artists, having multiple genres is very important.
Fourth, the head developer of Matroska (Steve) is a DJ, and one of the main focuses for him was to make a very powerful audio container. So if anything, many of the features are actually audio oriented.
@ spoon :
sorry for kind of hi-jacking this thread, but this is exactly the discussion we were seeking recently, as you may have noticed we are in the process of redesigning our tagging system.
Is it ok to go on reporting about our ideas and progress on this matter here, or should we use another thread ? BTW, jcsston has now started working on a fb2k plugin, based on DEATH's MP4 reader class ...
sorry for kind of hi-jacking this thread, but this is exactly the discussion we were seeking recently, as you may have noticed we are in the process of redesigning our tagging system.
Is it ok to go on reporting about our ideas and progress on this matter here, or should we use another thread ? BTW, jcsston has now started working on a fb2k plugin, based on DEATH's MP4 reader class ...
Sure here is fine.
If I can speak freely about the existing Matroska tags, I didn't like the use of non strings for storage of numbers.
If I can speak freely about the existing Matroska tags, I didn't like the use of non strings for storage of numbers.
Here is an idea for mp3 only,
how about a smart ape2 tag? that is for compatibility and APE2 tag is written followed by a ID3v1 tag, then if a player does not support the APE2 it will atleast read the APE2 tag. The code would be updating say artist in ape2 will update artist (as best as can) in the id3v1.
how about a smart ape2 tag? that is for compatibility and APE2 tag is written followed by a ID3v1 tag, then if a player does not support the APE2 it will atleast read the APE2 tag. The code would be updating say artist in ape2 will update artist (as best as can) in the id3v1.
QUOTE(Eli @ Dec 17 2003, 10:38 PM)
I havent seen it mentioned but there should be support for multiple artist fields. That way when A and B work togther you have:
Artist 1: A
Artist 2: B
NOT
Artist(s): A and B
So when you want to listent to something by A you can find even things that A worked on. Currently you would sorrt by "A and B" because they are linked together and the dumb tags think they are one entity when they are 2 or more.
There should also be support for multiple preferences, that way when multiple ppl use the library they can have there set of preferences. Or when ppl are listening at the same time the average of all of their preferences could be used.
Artist 1: A
Artist 2: B
NOT
Artist(s): A and B
So when you want to listent to something by A you can find even things that A worked on. Currently you would sorrt by "A and B" because they are linked together and the dumb tags think they are one entity when they are 2 or more.
There should also be support for multiple preferences, that way when multiple ppl use the library they can have there set of preferences. Or when ppl are listening at the same time the average of all of their preferences could be used.
I agree with this whole heartedly...
Categorizing music is often a fine distinction and having the fields organized like XML nodes with "unboounded" in their schema would rock.
I could then place a music file in several categories and carry around that meta data.
QUOTE(spoon @ Dec 18 2003, 02:34 PM)
Here is an idea for mp3 only,
how about a smart ape2 tag? that is for compatibility and APE2 tag is written followed by a ID3v1 tag, then if a player does not support the APE2 it will atleast read the APE2 tag. The code would be updating say artist in ape2 will update artist (as best as can) in the id3v1.
how about a smart ape2 tag? that is for compatibility and APE2 tag is written followed by a ID3v1 tag, then if a player does not support the APE2 it will atleast read the APE2 tag. The code would be updating say artist in ape2 will update artist (as best as can) in the id3v1.
Sorry that I have to say this but what you say is at least partially the way a LYRICS3 v2 tag behaves, so this is old news. As I said in previous posts please read carefully the tag standards that exist right now before trying to evolve/optimize anything otherwise we will be re discovering the wheel.
Again sorry for sounding like that but I feel that these things must be said.
The first draft of the new Matroska tagging system has just been completed. This new version supports nesting of attributes for any tag. There is also a proposed XML authoring format. Also, all tags are either UTF-8 or a binary dump of other data, so they should be readable no matter what writes them.
Working draft
Remember that this is a very rough draft so there are lots of little mistakes. But it should be very representative of the final product.
Edit: Changed URL to point to Matroska website specs as CVS has now been updated.
Working draft
Remember that this is a very rough draft so there are lots of little mistakes. But it should be very representative of the final product.
Edit: Changed URL to point to Matroska website specs as CVS has now been updated.
I did not see a LYRICS field, also it would be nice to include the ID3v2 APIC frame functionality up to some extend... comment is listed under image attributes is that ok ?, I would also like to see more 'classification' fields. A small note about DATES .. every tagging standard lists date fields but every software on the planet writes year values in them .. just because it is a lot more practical! so this is something I might wish for as well. explicit YEAR fields instead of DATES.
Nested tags are nice but they are complex and might scare developers away! most tagging software out there supports only basics fields from various formats even if those formats are simply flat data. I would be interested to listen to some idea of theoretical implementation in software of an XML nested tag field and how the user might interact with it in batch modes or use it in queries and cataloguing software.
Finally , where will this structure be located inside the physical file?
Nested tags are nice but they are complex and might scare developers away! most tagging software out there supports only basics fields from various formats even if those formats are simply flat data. I would be interested to listen to some idea of theoretical implementation in software of an XML nested tag field and how the user might interact with it in batch modes or use it in queries and cataloguing software.
Finally , where will this structure be located inside the physical file?
QUOTE(jtclipper @ Dec 20 2003, 02:06 PM)
I did not see a LYRICS field
This was actually already in there, but commented out for some reason. It shows now. Note that this is only UNSYNCHRONISEDTEXT as synchronized text in Matroska would be contained in a track.QUOTE
also it would be nice to include the ID3v2 APIC frame functionality up to some extend... comment is listed under image attributes is that ok ?, I would also like to see more 'classification' fields.
In Matroska, any pictures are attachments. The part for attachments in the Tags isn't actually shown yet, but there is not much change. I would refer you to the main attachment specs for Matroska. Beyond that the current tags allow you to Tag the image with all sorts of attributes.QUOTE
A small note about DATES .. every tagging standard lists date fields but every software on the planet writes year values in them .. just because it is a lot more practical! so this is something I might wish for as well. explicit YEAR fields instead of DATES.
The date fields will be in the format "YYYY-MM-DD HH:MM:SS.MSS" where the timezone is GMT and the space between DD and HH is 0x20. If you want to write the year, then only write "YYYY". QUOTE
Nested tags are nice but they are complex and might scare developers away! most tagging software out there supports only basics fields from various formats even if those formats are simply flat data.
Nested tags are used to produce detailed data, and so that in the future we might be able to use them to implement AAF support. We all expect that most applications will only deal with the first level of tags, skipping all of the rest.QUOTE
I would be interested to listen to some idea of theoretical implementation in software of an XML nested tag field and how the user might interact with it in batch modes or use it in queries and cataloguing software.
I would also be interested in peoples ideas. For displaying two levels of tags, you could just have the different parts of the second level right after the first. For example:
[ArtistName]->[Email][Phone] ; [BandName]->[URL]
Displaying anything more than two layers though would pretty much require the use of a type of tree view.
QUOTE
Finally , where will this structure be located inside the physical file?
Matroska has no real requirements about the location of items within a file. Other than the SeekHead (gives locations of other items) which should always be the first item, other items can be spread out anywhere in the file. In most cases, the Tags will likely be located at the end of the file so that it is easier to edit them. (room to shrink and grow) But if you wanted to, you could put them at the beginning (right after the SeekHead). There is no worry about taking a long time to load the Tags though because the SeekHead will tell an application right where the tags are so that you can just jump strait to them.
The new Matroska tagging system has been implemented in an fb2k Matroska input plugin now. One thing about it though is that the fb2k framework doesn't allow for nested tags so you can only add on the base level. Also, there is not a way to use the system to tag attachments. And finally, because this is just a container plugin, only MP3, AAC, and FLAC are supported so far with packet_decoder plugins. (You may notice some similarity to APEv2 design)
If you would like to see an example of this, then HERE is an example file. Its a full album in one file with the audio encoded using a single audio stream encoded to MP3, and Chapters to define song boundries. If you have the Matroska Shell Extension installed you will see the CD cover as the thumbnail. (Distribution permissions obtained)
What we really need from the HA community right now is help with the tag names. We are currently using all caps, with an underscore for a space. But for compatability with existing systems, we will be adopting terms such as "TRACKNUMBER".
So please, look at the Matroska Tags Specs and tell us if there is a different standard naming convention already being used for a specific tag.
If you would like to see an example of this, then HERE is an example file. Its a full album in one file with the audio encoded using a single audio stream encoded to MP3, and Chapters to define song boundries. If you have the Matroska Shell Extension installed you will see the CD cover as the thumbnail. (Distribution permissions obtained)
What we really need from the HA community right now is help with the tag names. We are currently using all caps, with an underscore for a space. But for compatability with existing systems, we will be adopting terms such as "TRACKNUMBER".
So please, look at the Matroska Tags Specs and tell us if there is a different standard naming convention already being used for a specific tag.
QUOTE(Pamel @ Dec 24 2003, 07:35 AM)
So please, look at the Matroska Tags Specs and tell us if there is a different standard naming convention already being used for a specific tag.
LOL .... no feedback, as usual. And afterwards they all come whining because they dont like what we did
.....
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.