similar to: oggz-comment hangs on multiple comments with same contents

Hi, It seems the oggz-comment on your computer has more features than the one you sent in August :-) Any chance you could send a more recent copy? In any case, I've updated the --help output for the -s option, and also added a manual page with the same info, in doc/oggz-comment.1.sgml (in svn.annodex.net changeset:3280). cheers, Conrad. On 07/11/2007, Kangyuan Niu

2008/11/24 David Flynn <davidf+nntp at woaf.net>: > On a slightly unrelated note, i keep hitting the following error in > liboggz when using the oggz tools on an ogg dirac stream: > > /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: > Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. > > I'll supply an example file tomorrow if that

2008/11/15 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >> It seems oggz chop, merge and sort will need some attention to deal >> with the Dirac granulepos and dependency ordering, so let's leave them >> for the next release. > > ok. -- may be worth having them 'warn' if they are operating

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 2008/11/15 David Flynn <davidf+nntp at woaf.net>: >>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >>>> It seems oggz chop, merge and sort will need some attention to deal >>>> with the Dirac

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: oggz-comment.patch Type: text/x-patch Size: 9771 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20070804/b06ca92e/oggz-comment.bin

Hi, I'm wondering if the Dirac granulepos parsing in liboggz and display in the oggz tools is currently correct, as I'd like to do a release of these soon. A couple of days ago David Schleef mentioned there were some problems. David, is that currently true (ie. since David Flynn's recent updates to support Dirac), and if so could you please explain what the problems are, or point me

Hi, I am using oggz-chop in the ubuntu jaunty, am I doing something wrong? $ oggz-chop -o yt1.ogv -s0 -e500 ondrej.ogv Segmentation fault gdb session doesn't reveal much, since it isn't compiled with debugging symbols: (gdb) bt #0 0x00007f9e5d2f0092 in memcpy () from /lib/libc.so.6 #1 0x0000000000403698 in ?? () #2 0x000000000040262e in ?? () #3 0x000000000040285d in ?? () #4

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

While testing the new vcut, some of the early results had badly framed headers. I actually didn't notice it at first, because I was testing with oggz-validate, but ogginfo does identify the problem: "WARNING: Vorbis stream X does not have headers correctly framed. Terminal header page contains additional packets or has non-zero granulepos" Conrad (or someone else) may want to

On 3/20/08, Conrad Parker <conrad at metadecks.org> wrote: > I agree that tools should now start writing media types without the x- . Cool. j^ reported that some of the tools in the Annodex SVN like mod_annodex, anxrip, oggz-merge, oggz-rip, etc will need to be modified. I do not have SVN access to edit these, so can one of you guys do it? With j's consent, I'll edit

I'm patching oggenc with this fix. If Conrad reports success in his test, I'll go ahead and patch all other implementations I can find. -Ivo

I'm patching oggenc with this fix. If Conrad reports success in his test, I'll go ahead and patch all other implementations I can find. -Ivo

Oggz 0.9.7 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-comment, oggz-scan, oggz-sort and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the

Oggz 0.9.7 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-comment, oggz-scan, oggz-sort and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the

When files with pre-0.9.9 tool names exists in $(exec_prefix)/bin, "make DESTDIR=${staging_dir} install" tries to delete them, which may cause a failure for lack of permissions (quite likely to happen when building a package as a normal user), and is wrong anyway (nothing outside of DESTDIR should ever be changed by "make install"). With this patch, it will now cd to

On 6/18/09, Conrad Parker <conrad at metadecks.org> wrote: > This sounds like it needs a new tool specifically for fixing broken > Ogg files. I see two solutions: 1) the new vcut which I reckon will fix the problem since it has to split and rebuild the audio in a new Ogg 2) an Hex editor, even if just to check what's wrong in the metadata section -Ivo

2008/7/16 John Ferlito <johnf at inodes.org>: >> Now there's the minor problem of upgrading from an earlier version of >> oggz, and having both versions of the >> tools around (eg. having an old oggzdump lying around even as >> oggz-dump is upgraded). What are your thoughts about ways to deal with >> this? eg. >> >> * On 'make install',

Package: liboggz Version: 0.9.0 Status: Severity: normal [Keep CC if you reply, I'm nt in this list] After porting the package to Cygwin, some binaries do not have accompnying manual pages. ... .inst/usr/share/man/man1/oggzdump.1.gz .inst/usr/share/man/man1/oggzdiff.1.gz .inst/usr/share/man/man1/oggzmerge.1.gz .inst/usr/share/man/man1/oggzrip.1.gz .inst/usr/include .inst/usr/include/oggz

Hi, not sure who to send this to, since it seems to be duplicated in both speex and liboggz, so I'm sending to the whole list. This fixes an off by one bug in the user of snprintf, and returns negative if writing the header returns negative (otherwise we'd just get a short write, losing the error). This patch isn't tested though, but I compiled it :) Also, I've not fixed this

Hi, not sure who to send this to, since it seems to be duplicated in both speex and liboggz, so I'm sending to the whole list. This fixes an off by one bug in the user of snprintf, and returns negative if writing the header returns negative (otherwise we'd just get a short write, losing the error). This patch isn't tested though, but I compiled it :) Also, I've not fixed this