similar to: Theora-tools: Theoracomment

Hi there, the attached patch for theora-tools adds UTF8 support to theoracomment; however, for this I did copy some "shared" files from vorbis-tools to theoracomment. I'm not sure whether you want this but rather make them shared in theora-tools, too? Additionally, I added header-comments in the style of theoraenc and a manpage. So far, theoracomment looks rather complete now

Hey all, I'm working on a media-database art project that basically stores a bunch of sound and video files, which are then navigated based on meta-data. I'm not sure where to start asking these, questions, here seemed like a good start. So I was thinking I should use an open format, like ogg/vorbis/theora. I also thought, will all that coll meta-data stuff in ogg I should be able to

Hi all, for theoracomment to work like vorbiscomment, I want to use that one's UTF8 library; but where should this go? Directly to theoracomment or is there something like a "common library directory" for theora-tools? I'm not sure about I18n, either -- theoraenc seems not to use GNU gettext at all, but vorbiscomment does; so should I put the i18n header to theoracomment,

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 for oggz-tools. oggz-comments - allows a user to pass the plain text file with each tag on their own line theoracomment - works like 'vorbiscomment' from VorbisTools package, but sets comments for the

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

I've attached updated patches (against vorbis-tools 1.3.0b3.5) to support comment padding. No changes to libvorbis are necessary. The padding is added in the same way as oggenc2 (null bytes within the packet, at the end) and shouldn't cause problems with any reasonable decoder or comment editor implementations. Padding is enabled by default, except for small files (less than 30 s for

-----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'm new to this list, and pretty much also to the codec universe. In a computer game I'm working on, there is an 3D TV-screen onto which I project the frames of a movie. The movie is of course stored as theora, no audio as it's not needed yet. I have it working so far, extracting a frame and uploading it to the graphics card when the scene is drawn. The example file

Dear vorbis-dev lurkers, I bring you the first beta release of vorbis-tools 1.3.0. It has quite a few new features and the final version will have even more, so I am sure it is to everyone's benefit that it gets as much tested as possible so we can do a quick release. Here's the changelog so far: * Fixed an error in configure.ac; --with-speex/flac work again (#1319) * Corrected

I sent a message about 2 weeks ago about build problems at the head of the CVS tree with non-gcc compilers on POSIX systems, although I didn't correctly identify the link problems as being static-library only (see my previous mail about "static link broken"). Some problems have been fixed, but some still seem to be there. I have edited my original mail to list the problems that

I'm trying to write comment writer thing for zinf, because I love the program, but it doesn't fully support ogg. I've found how to read comments, but can't figure how to write them. There has been some discussion about this previously in the archives, but I couldn't find any specifics, only references to code not posted to the list. The api documentation page is (painfully)

Hallo, I'd like to write a GUI (first choice with GTK+). I've surfed through the R- an Omegahat-Pages, because I'd like to use RGTK2, GTK 2.10.11 in combination with glade on Windows XP (perhaps later Unix, Mac). I've found a lot of different information. Because of the information I'm not sure, if this combination is running on Windows XP and I'm unsure how it works. Is

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

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:

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 don't think that the getopt_long() situation is handled correctly in the vorbis-tools module. Here's my take (comments welcome!). ----- This applies to oggenc, ogg123, and vorbiscomment. See http://www.xiph.org/archives/vorbis-dev/200012/0359.html for background and prior discussion on this issue. There are 2 issues: 1. Summary: getopt() is a POSIX function. It will already be on

"Kurosawa, Taku" wrote: > Hi Martijn, > > Sorry for the late reply again, > The application we are preparing this time is not exactly similar to > Replaygain. > > Replaygain as we understand is something which normalize the loudness at > content provider side, but our application takes different approach. It is > designed to normalize the loudness at player

On 2006-03-09 (Thu) ,at 23:20:50 Josh Coalson wrote: > the vorbiscomments are not in the streaminfo. you want to do: > > FLAC::Metadata::VorbisComment tags; > if (FLAC::Metadata::get_tags("somefile.flac", tags)) { > FLAC::Metadata::VorbisComment::Entry entry = > tags->get_comment(tags->get_num_comments-1); //e.g. last tag > // do something with

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:

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