similar to: Re: [xiph-commits] r14188 - trunk/vorbis-tools/vorbiscomment

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

--- vorbiscomment/vorbiscomment.1 | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/vorbiscomment/vorbiscomment.1 b/vorbiscomment/vorbiscomment.1 index 0108e78..2bceb83 100644 --- a/vorbiscomment/vorbiscomment.1 +++ b/vorbiscomment/vorbiscomment.1 @@ -39,13 +39,11 @@ Reads, modifies, and appends Ogg Vorbis audio file metadata tags. .IP "-a, --append" Append

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

Here's a patch that stops the flac binary from writing empty tag fields. At least in Windows world these come to files by accident. CD extraction programs pass all possible metadata entries they allow setting in the UI to flac binary and most of the time most fields are empty when basic info like artist, album, title, track number and release date are the only fields that are set.

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"

I think that vorbiscomment should really use -c "this=that" to specify tags on the commandline, consistent with oggenc. That displaces the tag source file, so I'd suggest -f, consistent with at least some other programs (although I can only think of tar, right now). I'd also suggest that it use -o for an output filename rather than splattering the second file on the

--- On Tue, 5/8/12, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Honestly, I really doubt this is a bug in valgrind :-). How > were you testing > this? Well, I've read that there have been bugs in valgrind, were SSE optimized versions of strlen() do guaranteed safe overreads of memory, but valgrind wasn't aware the overreads were safe. Anyway, it seems easy to

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:

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

Sounds good! Though maybe calling it oggz-metadata might make more sense? Cheers, Silvia. On Sun, Jun 13, 2010 at 1:42 PM, VolodyA! V Anarhist <Volodya at whengendarmesleeps.org> wrote: > Hi, > > I've sent one of these before, but i wasn't subscribed, and i'm unsure if it > went out. I'm subscribed now and i've written another (i believe) nifty > wrapper

-----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

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

On 11-Feb-08, at 6:00 PM, Erik de Castro Lopo wrote: > Personally, I think that change should be reverted and another > cleaner solution found to address that problem. Agreed, although it doesn't make that much differece; the code is broken either way. Ivo, if you don't want to do the alternate patch, you might ask the original contributor? -r

On 11-Feb-08, at 12:37 PM, ivo@svn.xiph.org wrote: > Author: ivo > Date: 2008-02-11 12:37:13 -0800 (Mon, 11 Feb 2008) > New Revision: 14479 > > Patch by Christian Weisgerber to fix possible problems in 64bit > systems with "int shuffle" and "int repeat". I'm confused. How does making these long help? -r

On 25-Jun-08, at 3:23 AM, ivo at svn.xiph.org wrote: > * correctness: make oggdec output help text on stdout instead of > stderr Hmm. Doesn't oggdec output the decompressed audio to stdout? IIRC the help goes to stderr to avoid clobbering that. If 'corretness' is the windows issue, could it be compile-time switched? -r

David K. Gasaway wrote: > Daniel Aleksandersen wrote: >> On Monday 17. September 2007 07:47:19 David K. Gasaway wrote: >>> Even today, I use my own "metadata format" -- essentially a superset of >>> vorbis comments. There is one file per release, even with a multi-disc >>> release. As a final part of the ripping process, I apply this metadata

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

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),