I wanted to post publicly my problem with Jonathan's proposed album requirements. Although I do apologize, since this thread is too big already. The idea that as a requirement one should be able to identify the exact CD a track was ripped from is not a valid requirement in my book (not for the tags at least), and I hope I can explain why. Without knowing the exact way Jonathan wishes to accomplish this, I must resort to what I hope is fair conjecture. One way to do it would be to limit the ALBUM tag so that there is only one entry listed will eliminate the ability to list all the albums that a track has appeared on. Knowing that a track was on 4 albums is far more important to me than knowing only that user X ripped it from some particular album. An alternative is to add yet another new tag to say which album the track was taken from, but I don't think the solution is even more tags (although I admit that is the extent of my disagreement with this solution). Another alternative then is to use some CDDB or Songprint/Musicbrainz entry to identify the song. I object to CDDB being in the tags because a CDDB entry is a computer-id and not a human id. That's what we will have the structured metadata (which has yet to be designed) for - computer data, non-human type data (among other things) that is to be used and not displayed verbatim. Don't push metadata into the tags just because the metadata hasn't been designed yet, use it as the excuse to design the metadata. We've suffered from bad designs to ease simplicity with other formats, let's not repeat the mistake. Addendum: Anyone who proposes caching a Songprint, Musicbrainz, or other audio fingerprint in the file obviously doesn't understand the goals of an audio fingerprint: to properly identify a song without having to refer to tags. To cache a fingerprint accomplishes the same thing as storing the title, artist, etc. in the file. The data is no more reliable. So as not to be criticized as being purely dismissive, my proposal is to earmark "identifying the CD it came from" as a feature to consider when planning the structured metadata. Jon <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Fri, Dec 07, 2001 at 05:18:03AM -0500, Jon Shiring wrote:> Addendum: Anyone who proposes caching a Songprint, Musicbrainz, or other > audio fingerprint in the file obviously doesn't understand the goals of an > audio fingerprint: to properly identify a song without having to refer to > tags. To cache a fingerprint accomplishes the same thing as storing the > title, artist, etc. in the file. The data is no more reliable.ID3v2 has a MCDI tag for storing the CD TOC (from that, any hash could be generated). Unfortunately AFAIK not a single program implements it. It's binary data, which makes things fun. Is there a standard for escaping linefeeds and such in vorbis comments? -- Robert Woodcock - rcw@debian.org "There is no device that can distinguish between a fair use and a non-fair use." -- Allan Adler, VP Legal Affairs, American Publishers Association --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Jon Shiring wrote:> Knowing that a track was on 4 albums is far more > important to me than knowing only that user X ripped it from some > particular album.Actually, I would like to know what album a track came from, because it makes a big difference (in terms of audio quality) whether it came from a disc released in 1985 or one released in 2000; the quality of digital mastering now is much better. Also, sometimes the version of a song on a greatest hits package is not quite the same as on the original album; it may have been edited for radio, for example, though there might be no indication on the CD packaging that this was the case. And of course, the version on a live concert album will not be the same as a studio recording. In fact, for albums which have been released on CD more than once (either remastered by the same label, or put out on different labels at different times, or even just different simultaneous international releases not made from the same digital master), I'd like to know exactly which version was used. The big problem is that most users aren't going to bother putting in all this detail, which renders this whole issue largely moot. In my experience, many MP3 users don't put _any_ tags in their files, and those that do rarely go beyond "artist", "title", and maybe "album" -- if you're lucky, you get "track number" and "year" (often wrong). "Genre" seems to be chosen largely at random when it's used at all. So it seems to me like pure delusion to think that most ogg users are going to correctly fill in any significant percentage of Jonathan's big list of tags. Of course, Jonathan himself presumably will, but there's no need for a "standard" if we're just talking about him. Ogg's (or Vorbis'?) tag format is open-ended for a reason; he can use it any way he likes without insisting that everyone else do likewise. Craig --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Fri, Dec 07, 2001 at 05:18:03AM -0500, Jon Shiring wrote:>The idea that as a requirement one should be able to identify the exact CD >a track was ripped from is not a valid requirement in my book (not for the >tags at least), and I hope I can explain why. Without knowing the exactWhile I disagree with you on that point, you have convinced me that we should not include DISCID, FREEDB, ID:FOO, or other such tags in the standard. Unless someone speaks up in their support, consider them stricken. Such tags are useless for locating a CD in disconnected operation. The ISBN tag will stand for now unless someone else has a good reason for ommitting it. With ISBN at least, you only put it in if it is on the CD cover. In which case it is something that you can write down and compare to the CD cover at the record store. Jonathan>Another alternative then is to use some CDDB or Songprint/Musicbrainz entry >to identify the song. I object to CDDB being in the tags because a CDDB >entry is a computer-id and not a human id. That's what we will have the >structured metadata (which has yet to be designed) for - computer data, >non-human type data (among other things) that is to be used and not >displayed verbatim. Don't push metadata into the tags just because the >metadata hasn't been designed yet, use it as the excuse to design the >metadata. We've suffered from bad designs to ease simplicity with other >formats, let's not repeat the mistake. > >Addendum: Anyone who proposes caching a Songprint, Musicbrainz, or other >audio fingerprint in the file obviously doesn't understand the goals of an >audio fingerprint: to properly identify a song without having to refer to >tags. To cache a fingerprint accomplishes the same thing as storing the >title, artist, etc. in the file. The data is no more reliable.-------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 797 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis/attachments/20011207/b9c74cc8/part-0001.pgp
On Friday 07 December 2001 23:18, Jon Shiring wrote:> Another alternative then is to use some CDDB or Songprint/Musicbrainz entry > to identify the song. I object to CDDB being in the tags because a CDDB > entry is a computer-id and not a human id.It's useful for correlating a track back to a particular CD it came from. This way I can rip a CD with RC2, tag it from freedb, tidy those tags and add more information, and when it comes time to upgrade to RC3/v1.0/v1.* with wavlets I can can feed the software any given cd from my collection, and it will find files that where ripped from that cd, reencode them and migrate the tags. Anything that saves me huge quantities of typing has got to be a Good Thing.> Addendum: Anyone who proposes caching a Songprint, Musicbrainz, or other > audio fingerprint in the file obviously doesn't understand the goals of an > audio fingerprint: to properly identify a song without having to refer to > tags. To cache a fingerprint accomplishes the same thing as storing the > title, artist, etc. in the file. The data is no more reliable.But it is a good idea to cache the data if the fingerprint algorithm is computationally intensive, and there exists some application that will need to place fingerprinting inside a loop of some sort.> So as not to be criticized as being purely dismissive, my proposal is to > earmark "identifying the CD it came from" as a feature to consider when > planning the structured metadata.I'd like enough information to be able to figure out what CD the ablum came from 95% of the time - which is something that the album field has been able to accomplish, in general. However, not everyone distributes there music via the usual channels, or even in physical form, so a 'pay me if you think the song is good' url field would solve that problem. Actually, some thoughts on that, while I'm thinking about it: - The field should store an URL, rather than being wedded to some particular payment scheme. That way you can link to Amazon, or your record label site, or your own site, or your paypal account - whatever you like. - The field should be distinct from any other information url, so as to provide the quickest path to being paid. - Standardising on a field earns ogg lots of smurfy goodness for being proactive in the keeping the artists feed department. John --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.