>I don't mind (and approve of) the idea of reusing as much of proven >standards as we can. But putting it in a Vorbis comment will in fact >piss off people who then can't play the file. It's not as much a >qestion of displaying the tag as text (although that is a concern) >it's that most hardware players that only have 10-20kB available for >stream buffering won't be able to decode the headers and thus won't be >able to play the file.OK, I haven't been aware of those problems with hardware players. Are most of them actually unable to skip comment fields which are (too) big for them? And wouldn't cause any other embedded cover art implementation compatibility breaks with existing hardware players too? Beside that, I think this problem is manageable since --> you can also link the cover art within the ID3 / FLAC tag structure and therefore keep the size at a level which is supported by hardware players, --> notify the user within a software tagger when *embedding* the cover art that his hardware player *might* not support this and that the user should first test this on his hardware. --> software developers can easily adopt their cover art implementations for OGG files because of the standard which is already in wide use (if this is even necessary, C and C++ based software shouldn't face a problem anyway because of the leading zero bytes) The currently existing base64-encoded thing within the vorbis comments also breaks with hardware support and has no support for any additional cover art information, I therefore think the ID3 / FLAC tag structure is simply better and more flexible. -m
I have more than once said I'm in favor of the vorbiscomment solution. It's ugly, it will break this and that one other player, but these people want the feature that bad so they won't mind about any of those issues. Plus it means little or no work for a feature the people who actually do code care little about, and it certainly helps that there's already at least one implementation out there. So, my solution: * state COVERART is used to contain base64 JPEG * state it may break some limited players * let those users who want the feature be happy with it and not lose them; they won't mind stripping off the tag for the few cases that will require it and they will stop the constant complaining about "OGG SUCKS IT DON'T DO ALMBUART" For Mathias: you want a combination of stuff that is presently not available in Ogg and will certainly take a good long while until there's libraries and software to do PDF+SVG encapsulation and proper playback. Just go with a standalone PDF for now, that would be my recommendation. -Ivo
Hi, [ Was away the last few days, so this partly overlaps on things that that have been mentioned in this thread. Since the consensus seems that Vorbis comment encoding is the way to go, it's a bit moot, but here it is anyway ] Following up on the possibility to tag various images as different types of album art, I thought of adding that tagging information in a Skeleton stream. Since Skeleton's purpose is to describe the set of tracks in a physical bitstream, as well as the relationship between those tracks, it is well suited to such a use. So, a possible way to encode album art would be: - a Skeleton stream with appropriate header messages - one Kate stream per image, carrying a PNG image (alternatively, use Ogg/MNG, if someone brings it from the dead) The semantics of those images would be carried by predefined message headers in the Skeleton stream. Something along the lines of (for each separate image stream): X-Content-Semantics: album art X-Album-Art-Type: front cover (or back cover, etc) There would be some overhead with having one stream per image: Kate headers would weight at 162 bytes for header payload, plus two Ogg frames at 29 bytes each, and would be per image rather than per file. If carrying a 25 KB PNG image, this is only about 0.1% though. One drawback is streaming, where all of this is stuffed into the headers, so there's a biggish hit at connection if sending a stream loaded with images. Caveat icecast operator I suppose. Icecast could also be made to automatically strip those as an option too, if needed (I'd have to look, not sure if this'd be that easy to do). This is a good chance to actually have Skeleton used for what it's meant to be (AFAICT): relationships between tracks: one could define a particular image to be related to a particular track, if a whole album gets encoded as several Vorbis tracks in a single stream. Most of the images would be common to all tracks, but some could be track specific. This could also be used for lyrics: map a given lyrics track to the matching Vorbis track. Is there a list of relationships that Skeleton can define somewhere, or is this not done yet ?