Hello to the people reading this list! I am developing tagging support for ogg vorbis in Nero products and we are currently thinking of supporting cover art in ogg files. What is the current state of proposal for cover art in ogg files? Is this http://wiki.xiph.org/index.php/VorbisComment#Cover_art still the latest information? Regards, Goran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090326/94c6935d/attachment.htm
2009/3/26 Goran Markovic <skromnibog at gmail.com>:> I am developing tagging support for ogg vorbis in Nero products and we are > currently thinking of supporting cover art in ogg files. What is the current > state of proposal for cover art in ogg files? Is > this?http://wiki.xiph.org/index.php/VorbisComment#Cover_art?still the latest > information?As far as I know, yes. Let us know what you think. -r
> The granulepos 0 errors are probably due to the comment packet not being > split up correctly (the pages carrying fragments before the end should > be granulepos -1)Well OK, I've reviewed my code and I actually write a granulepos of 0 to all header pages. I did this because the specification explicitly says that "The granule position of these first pages containing only headers is zero." and "Granule Position must always increase forward or remain equal from page to page, be unset, or be zero for a header page." This is specified at http://xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-130000A.2 (the 4th point of the list) and http://xiph.org/ogg/doc/ogg-multiplex.html (section "Granule Position", "Description", first point of the list) It however seems that also the non-finishing *header* pages must have a granulepos of -1, I'm going to fix this within my library. I haven't been aware of that, and in my opinion the specs are misleading in that point.> I'm a bit puzzled about the structure: how did you do the> Ogg encapsulation? When I try this with ogg_stream_pageout I get the > comment packet split across 4kB pages (because that's what libogg's > pageout aims for), your example has about 6 pages, which is what you'd > expect for splitting the image across maximum size pages.My tagging library actually splits the comment header across the maximum page size. I thought this would be the best behaviour to avoid re-writing the entire file: if one removes the included image again, I can a) simply shrink the last page of the comment header without touching any other page, or b) replace no longer needed pages with null pages so that I don't have to change the page sequence number, so that I don't have to re-compute the checksums for all pages within the file. Or is there any reason why I shouldn't do it like this?> Okay, I've basically just run this through vorbiscomment with the -a > flag and no tags specified, which results in re-paging (I was going to > write my own tool to do it, but the large initial pages make that > difficult without re-paging the whole stream). Have checked that it > passes oggz-validate, plays and still contains the picture block.OK, I'm going to update the test file on my server.> Actually on the subject of the picture block, it's UTF-8 encoded. > After looking at the comment header spec. again I believe this is > correct, but it needs a note in the cover-art proposal that this is > what happens.Well the ogg vorbis specs say that comments are UTF-8 encoded, but that makes no sense anyway when placing binary data into the vorbis comment. The description of the picture within the binary data itself is also UTF-8 encoded, as specified within the FLAC comment header structure at http://flac.sourceforge.net/format.html#metadata_block_picture Mathias.
I managed to find some time and implement extracting cover art from the demo file. I have some more questions:> > Okay, I've basically just run this through vorbiscomment with the -a > > flag and no tags specified, which results in re-paging (I was going to > > write my own tool to do it, but the large initial pages make that > > difficult without re-paging the whole stream). Have checked that it > > passes oggz-validate, plays and still contains the picture block. > > OK, I'm going to update the test file on my server.Where can I find this file? The one at http://wiki.xiph.org/index.php/VorbisComment#Cover_art is still the same.> > Well the ogg vorbis specs say that comments are UTF-8 encoded, but that makes no sense anyway when >> placing binary data into the vorbis comment. The description of the picture within the binary data itself is also >> UTF-8 encoded, as specified within the FLAC comment header structure at >> http://flac.sourceforge.net/format.html#metadata_block_picture > > Yes it's not ideal, but I'm reasoning on the basis that all the specs > dealing with the vorbis comment headers (or its clones in other > formats) require the comment contents to be UTF-8 encoded. This > presumably means the picture description is UTF-8 encoded twice.> I was wondering about this myself, as the proposal on > http://wiki.xiph.org/index.php/VorbisComment didn't mention anything > about UTF-8 encoding the binary content of the coverart structure, > although it's done in the demo file. If not doing it, arbitrary binary > content is most likely not a valid UTF-8 sequence and may cause current > software to fail.This should be mentioned explicitly for "BINARY_COVERART" on the page http://wiki.xiph.org/index.php/VorbisComment#Cover_art. One must also have in mind that using Microsoft's CA2W will not work for BINARY_COVERART. It works for all other comments (text) because 0 is terminating string for both UTF_8 and for Unicode. Code which uses CA2W for converting comments from UTF_8 to Unicode will thus have problems with BINARY_COVERART.>> 33%. Even if older software displays the Base64 comment value as a string, >> it's unlikely that the comment is ignored completely, as is the case with >> e.g. WinAmp. Not only is the BINARY_COVERART not shown in the file info >> dialog, but it's removed from the file if other comments are edited with >> WinAmp.This is probably a bug that should be fixed in WinAmp. They shouldn't allow changes in comments that are not supported by the software, but leave them untouched.> Completely off-message suggestion follows: > It's things like this that really argue for the sense of doing the > multiplexed approach... > > How about: FLAC picture block packets + some kind of modified FLAC bos > to identify as a cover art stream? Compromise between quick-hack and > technically elegant. (For those people upset by the other off-message > suggestion that both PNG and JNG could be encapsulated following the > MNG-Ogg format.)Talks like this make me rethink about supporting cover art for ogg in next Nero release. I hope that support for cover art in ogg will be definitely standardized very soon.
> Yes, please ignore that last bit; it is really about next generation > stuff for general Ogg cover-art, but the Vorbis-I format (i.e. Ogg > Vorbis files) is quite rigidly fixed, so the comment tag approach > you're pursuing is the one that's needed. What you've already > implemented is not wasted as the only thing I can really see changing > is exactly how the FLAC picture block is placed in the tag contents.The problem is writing of cover art to ogg files. To support writing of cover art, cover art format should be standardized as soon as possible. Nero doesn't want to create files with cover art that in future will not be supported by other software or hardware.> Is the possibility of linking the art provided by the FLAC structure > (I can't see it in the format) or was it supposed to be an alternative > use for the COVERART tag?It is defined in FLAC structure: "The MIME type may also be --> to signify that the data part is a URL of the picture instead of the picture data itself."> Why is "-->" used as a pseudo mime type to indicate that the binary > picture data contains a URL to the image instead of the registered MIME > type "text/uri-list"?FLAC picture block is based on APIC frame in ID3v2. From there come definitions of picture type and this "-->".> The byte order is not clearly stated. It's only mentioned in the > METADATA_BLOCK_VORBIS_COMMENT field description, that that field uses > little-endian order as opposed to the "usual" big-endian order in other > FLAC fields.In FLAC picture big-endian order is used.> How should multiple images be embedded? Several METADATA_BLOCK_PICTURE > structs concatenated in one comment field, or several comment fields > with the same name, each containing one METADATA_BLOCK_PICTURE struct? > Some of the picture types indicate that the image order is relevant, > e.g. leaflet pages. If each image is put in separate comment fields, > will e.g. libvorbis (or other Vorbis decoders) retain the comment field > order, so that supporting software is able to show the images in the > correct order?I would prefer several comment fields, each containing one picture. It is much easier for handling. Order for same cover art type is of course important.> I've just updated it on my server. You can now get the new re-paged ogg file > (from Ian Malone, thanks) from http://www.audioranger.com/with_coverart.ogg > The old one is also still available at > http://www.audioranger.com/with_coverart_old.oggGreat! Thanks! As expected extracting the cover art from the new file works without any changes in the source code :)> If you're going to use the flac metadata format, I'd suggest being > explicit about that in the tag name, with FLAC_PICTURE or > FLAC_METADATA_BLOCK, etc. instead of a generic COVERART tag. Do you > propose to include the block header with the internal length, or just > the picture block?Hmmm. Another new proposal. Who is responsible here for setting standard? Who can guarantee that it will not change (unless of course at some point some big problems arise)?> If I'm right then the score currently stands at: base64 encoded FLAC > metadata block in a tag named 'METADATA_BLOCK_PICTURE'.'METADATA_BLOCK_PICTURE'? Why? Why not stick to 'BINARY_COVERART' I guess software and hardware players should be checked again with this new encoding. P.S. Sorry if I answered something that was already answered by others.
Mathias Kunter <mathiaskunter at yahoo.de> wrote: ...>> Do you propose to include the block header with the internal length, >> or just the picture block? > > I'm not sure what you mean here. The length of the > BINARY_COVERART comment within the ogg comment > header must be the length of the base64-encoded > string anyway. After decoding this base64 string into a > byte array, this array should be parsed like the FLAC > specification suggests.Including the length of the metadata block is important for devices with limited memory. Cover art, however it is encoded, is big compared to other VorbisComments. The inclusion of the block length allows devices to easily skip the block. Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/
I've again updated the test file which is linked on the wiki, it's now a file containing a base64 encoded FLAC picture structure which is placed within a METADATA_BLOCK_PICTURE tag. imalone, the test file you sent me still used the old comment name (BINARY_COVERART) for the base64 encoded data, I've therefore created a new file. Please check that the file which is available from my server now at http://www.audioranger.com/with_coverart.ogg is a valid one (just to be sure, it should be fine). Thanks :-) You can also send me your (corrected) version of the file with the embedded picture again so that I can host it as an additional test file on my webspace. Mathias
Thanks to everybody that helped for cover art to reach its final form!
Hello, the specification is online at the Xiph wiki at http://wiki.xiph.org/index.php/VorbisComment#Cover_art I hope this helps! Mathias ----- Urspr?ngliche Mail ---- Von: Stevo Brock <stevo at monkey-tools.com> An: Mathias Kunter <mathiaskunter at yahoo.de> Gesendet: Freitag, den 17. April 2009, 00:33:54 Uhr Betreff: Re: [Vorbis-dev] Cover art Hi Mathias, Where can we find the definitive info on embedded cover art for Vorbis files? -Stevo Brock Head of Development Monkey Tools, LLC www.monkey-tools.com On Apr 16, 2009, at 1:30 PM, Mathias Kunter wrote:> > You're welcome. > > I've written to many software developers in the meantime in order to inform them about the new format for embedded cover art. This should help to establish the new standard soon. > > Mathias > > > > > ----- Urspr?ngliche Mail ---- > Von: Goran Markovic <skromnibog at gmail.com> > An: vorbis-dev at xiph.org > Gesendet: Donnerstag, den 16. April 2009, 14:57:58 Uhr > Betreff: [Vorbis-dev] Cover art > > Thanks to everybody that helped for cover art to reach its final form! > _______________________________________________ > Vorbis-dev mailing list > Vorbis-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/vorbis-dev > > > > > _______________________________________________ > Vorbis-dev mailing list > Vorbis-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/vorbis-dev