similar to: vorbiscomment and UTF-8

Could someone please tell me what I'm doing wrong here? I have some oggs tagged using other applications and ogginfo doesn't give me any warnings when I use UTF-8 in them. I did the following: $ vorbiscomment --raw -a test.ogg -t "test=åäö" $ vorbiscomment --raw -l test.ogg test=åäö $ ogginfo -v test.ogg Processing file "test.ogg"... New logical stream (#1, serial:

Hi, The following changes allow vorbiscomment to read and edit the tags for the first occuring vorbis stream in a muxed (and chained) Ogg bitstream, while retaining the renormalisation. I've tested it on a number of combinations of muxed and chained streams, using the write comments from file option for vorbiscomment to rewrite the comment header and then cmp for binary differences. Seems

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, how about adding an option to vorbiscomment that displays it's version? This would make it considerably easier to do version- checking. Right now, I'm looking for a string that is only available in vorbiscomment > RC1 but that's not really the cleanest solution ... - -- - -M - ------- Magnus von Koeller

As I understand it, any attribute=value line in a vorbis comment can be arbitrarily long (up to 2^32 -1 bytes). The easytag program allows adding the album cover art and other images into the vorbis comment as ALBUMART=xxxx where xxxx is a base64 encoded data of the image file. This makes for a very long line. If I do this to extract the vorbis comment of a file with an embedded cover art (the

I'd like someone to clear up, or point me to some document clearing up, the character encoding for tags. In some of my OGG:s, non-ASCII characters show up like this: ? -> a ? -> "a ? -> "o etc. While when I set new tags, they later all show up as '#'. What kind of encodings are used in these cases. Which is preferred? (I have no LC_* environment variables set,

I don't agree with the s/Ogg Vorbis/Vorbis/. vorbiscomment does edit Ogg Vorbis files, not Vorbis streams in any other encapsulation. -r On Mon, Nov 19, 2007 at 07:01:43AM -0800, ivo@svn.xiph.org wrote: > Author: ivo > Date: 2007-11-19 07:01:43 -0800 (Mon, 19 Nov 2007) > New Revision: 14188 > > Modified: > trunk/vorbis-tools/vorbiscomment/vorbiscomment.1 > Log:

Hello, I am writing a script which reads and writes vorbis comments using the vorbiscomment utility from vorbis-tools. I have just one question regarding the --raw switch. Raw mode (--raw, -R) will read and write comments in utf8, rather than converting to the user's character set. This is useful for using vorbiscomment in scripts. However, this is not sufficient for general

Hello, I am writing a script which reads and writes vorbis comments using the vorbiscomment utility from vorbis-tools. I have just one question regarding the --raw switch. Raw mode (--raw, -R) will read and write comments in utf8, rather than converting to the user's character set. This is useful for using vorbiscomment in scripts. However, this is not sufficient for general

Some of these things may allready be addressed: Comments in oggfiles: (meaning the accutall keyword "comment(s)" With xmms you can edit oggtags, among artist and title you have "comment" * xmms creates comment attributes starting with "=" * freeamp does not seem to understand ogg-"comment" at all. * oggenc seems to like to put the comment as is without

As far as I could find, nowhere in the documentation or even source does it actually explain how to use vorbiscomment. Just a simple "vorbiscomment reads TAG=VALUE pairs on separate lines from stdin" would save people a lot of time. Of course, this is still a painful tool to use, and since I had some .ogg's lying around with broken comments (from my first ogg vorbis patch to grip),

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as I said before on this list I use the vorbiscomment utility in my music file management perl script and I've just noticed that it has huge problems with German umlauts. "ö", for example, becomes "ö", which is QUITE annoying. In xmms, the tags are displayed correctly, though. I'm using the newest libraries and

I'm writing a couple of reader/writer functions for a music tag class for python that can read and write 'raw' vorbis comments to text files[1]. I want these text files to be basically the same as the output/input comments used by the vorbiscomment program, but while testing out multi line comments I discovered that while vorbiscomment can set them with a -t "tag=value"

Sorry if this is offtopic. My Win32 comment editor uses a routine of my own to read comments directly from OGG files but uses vorbiscomment.exe to write comments. I've implemented a UTF-8 function which I found on the internet to decode UTF-8. It appears to be working fine for most European characters, however, I have a Russian user using WinXP who is entering Hebrew characters such as

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just installed RC3 after getting home from my Christmas vacation and am disappointed to find that the vorbiscomment utility still doesn't include a way to check it's version at the command line. There was some talk on this list about adding a --version or -V command line switch to read out the version. Could sombody please add one

This will be the last announcement of WinVorbis releases on this list. Visit the website to keep up to date. WinVorbis is now UTF-8 compliant! For some reason VorbisComment doesn't support UTF-8 characters in tag names, only in tag data. Added a case conversion routine which uppercases the first letter of every word and lowercases the rest. It is implemented in the templates by using

Attached is a patch that adds 5 missing FLAC__metadata_object_vorbiscomment_* functions to the VorbisComment class. In my previous message I stated 8 functions were missing, but on closer inspection, 3 of those belong in the VorbisComment::Entry class, and 2 of them already have equivalent functions in there. The last one (FLAC__metadata_object_vorbiscomment_entry_matches()) does not, but I have

I have been tidying up the VorbisComment page in the XiphWiki. The problem with it was that it was a mixture of proposals and discussion of those proposals. This made it difficult for implementers to see what to implement. The problem section is: http://wiki.xiph.org/index.php/VorbisComment#New_ENCODER_field_name_proposal This is a mess, and all I could do was add attributions to the

I have written up a z shell completion function for the Ogg Vorbis metadata editing program, vorbiscomment. It is attached, and available at http://netwood.net/usr/jessw/_vorbiscomment The Z shell is an alternative shell, with a very powerful completion system. I look forward to any suggestions, bug reports, etc. Feel free to include the file in the distribution, or link to it, as you

I just moved a bunch of shared code (like 4 copies of getopt) into a share directory within vorbis-tools. I also moved the UTF-8 code from oggenc into the vorbis-tools/share directory as well so that it could be used by all of the tools, since they all need to handle UTF-8 comments correctly. Header files for the shared code are stored in vorbis-tools/include. I have already fixed vorbiscomment

Silvia, This discussion has moved to vorbis-dev. You may want to reply further there. On 4/12/08, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > Even with putting the picture into vorbiscomment, the software would > need to be smart enough to uudecode the picture and display it. A url > is much simpler I believe. I had thought of this approach myself, too, and while