similar to: vorbiscomment bug

Hello, I've been trying to create a new ticket in the xiph.org trac instance. I'm able to enter ticket details at https://trac.xiph.org/newticket, but when pressing "submit ticket" I get a "403 Forbidden" message. I was able to create a ticket just last week: https://trac.xiph.org/ticket/1085, so the problem seems to be new. Thanks. (I hope this is the right place

> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Exciting! > > (btw, I'd prefer libfuzzer at googlegroups.com <mailto:libfuzzer at googlegroups.com> for such discussions, please start new topics there) You mean a LLVM library has a separate mailing-list? Why? — Mehdi > > I can reproduce this too, but

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

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! I think it is supposed to save all the comments in UTF-8 encoding. But I think all files I write to my files with 'vorbiscomment -w file.ogg -c tag' are saved in standard ISO-8859-1(5). How can I change this? Thanks for help. Stefan --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a

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

Hi I've a bug in vorbis-tools's libutf8 - some share/*.[ch] files don't include config.h; as a result, utf8.c:convert_set_charset doesn't try charset = nl_langinfo(CODESET) which would correctly return UTF-8, because HAVE_LANGINFO_CODESET isn't defined (it's defined in config.h, but config.h is not included). So, the bugfix is simple - just include config.h everywhere

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

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

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

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

> On Sep 21, 2016, at 12:56 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Sep 21, 2016 at 12:32 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:

Sorry for spamming but in the haste I forgot the stream_decoder part out. On 26.9.2014 15:47, Janne Hyv?rinen wrote: > On 26.9.2014 15:21, Erik de Castro Lopo wrote: >> Janne Hyv?rinen wrote: >> >>> Patch v2, now handles more malformed cases. Original patch was for a >>> file for which I had a sample from a user but this allows handling some >>> manually

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

Hello, Is this reproducible? > Fuzzing is a probabilistic business and one or even two runs don't prove > much. > I've reproduced the behavior on two different machines. Attached is a script to do so. To use the script, - create an empty folder and copy both prune-blocks.sh and ff-http-parser.sh in there - ensure clang and clang++ are in your $PATH - cd /path/to/prune-blocks.sh

Hallo again! Some month ago we discussed about the Vorbis Comment Chapter Extension: http://wiki.xiph.org/Chapter_Extension I got some critics about this specification, especially from the VLC developers: see https://trac.videolan.org/vlc/ticket/6895 Some parts of it: <cite> This specification allows holes between chapters and allows overlapping chapters... And does not explain what to