erland;275188 Wrote: > I'm not sure the order is guaranteed in all tagging programs, so you > might get a hard time to relate the CREDIT and CREDITSORT tags to each > other. But I suppose this could be handled by just having a CREDIT tag > that contains three fields, the "type", "name" and "sortname". > > Sorting is probably also needed for the TAG tags. >
Of course you are right :). I wrote this "only two generic tags" example to demonstrate how (IMO) a generic, simple and versatile tag design could work. A "simple" design like this could be part of SC core and let anybody organize its music as it wants. In fact, if I had really decided to go this way, I would have studied more ID3 internals and would probably have come to the creation two tags with complex structure like: CREDIT=<credit_type1>|<name1>|<sortname1>§<credit_type2>|<name2>|<sortname2> TAG=<tag_name/type1>|<tag_value1>|<tag_sort1>§<tag_name/type2>|<tag_value2>|<tag_sort2> It's far from being perfect: - content tag analysis make it not too easy to manipulate with tools like mp3tag, - totally incompatible and redundant with "advanced standard tags", - totally incompatible with any existing hardware or software, - need of character escaping for field separation inside tags, but it was mainly to show that things can be done and we're not doomed to accept this narrow (silly?) artist/album/track philosophy. erland;275188 Wrote: > > The advantage of this compared to just using custom tags is that it > would be easy to scan them since you know that every TAG and CREDIT tag > contains relevant information and should be scanned. Custom Scan > currently can't scan every tag because there is just too many tags that > isn't relevant when browsing your library, the result is that the user > has to configure exactly this tags that should be scanned. > > It should be pretty easy to make a scanning module for the Custom Scan > plugin that can scan CREDIT and TAG tags that looks like this. These > will then also be possible to use when browsing with the Custom Browse > plugin. In my current project, I don't really need this "only two generic tags", but I think this could (that is to be discussed) be great for a bundled "ready to use customscan/custombrowser package". Along with pre-configured "dynamic browsing" and a good wiki page, it could fit most exotic advanced tagger amateurs. But to prevent obsolescence of tags inside media files, I still think that the user should keep data out of media files for example in a txt, csv or xls file (who said xml?;) ). -- vrobin ------------------------------------------------------------------------ vrobin's Profile: http://forums.slimdevices.com/member.php?userid=11705 View this thread: http://forums.slimdevices.com/showthread.php?t=43851
_______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
