similar to: eos on continued page

2009/6/26 Adam Rosi-Kessel <adam at rosi-kessel.org>: > Can I fix the checksum with a hex editor? I just realized that the hogg tools will fix the CRC issues (by design accident: hogg ignores the CRC on reading but sets it correctly on writing). "hogg rip" rewrites the pages (fixing the CRC), and "hogg reconstruct" also rewrites the I've uploaded the outputs of

2009/7/18 Adam Rosi-Kessel <adam at rosi-kessel.org>: > On Fri, Jul 17, 2009 at 12:48:27PM -0700, Ralph Giles wrote: >> > In my ongoing quest to restore corrupted ogg files, I'm trying to find >> > an easy way to identify the setup header without having to actually >> > decode it. I understand that it starts with [packet_type] = 5 and then >> > the

On Sun, Feb 24, 2008 at 5:54 PM, Conrad Parker <conrad@metadecks.org> wrote: > Is this a bug in libogg (should it assign eos to the last completed > packet on the page marked eos), or in the specification (should it say > that the last page must not contain any incomplete packets, in which > case a page chopper will have to rewrite the last page and remove > them)?

On 25-Feb-08, at 3:42 PM, Conrad Parker wrote: > ok. If the correct behaviour should be to ignore the incomplete > packet, that should also be clarified in the spec. Fair enough. What if no packet ends on the eos page? What about additional pages after the eos page? > I'd find it useful if it was not considered a structural error, as it > allows us to very simply chop files

On 26/02/2008, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > Hmm, good point. Maybe it requires a MUST specification... But then, it > would not be conformant to have a partial packet on the last page.... I'd definitely prefer that the recommendation to not have an incomplete packet on a page marked eos is a SHOULD not a MUST, so that eos pages don't need to be

On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote: > I'd say both; libogg should ignore the incomplete packet or flag a > structural error, and the spec should be clarified. I guess libogg should return -1 if you try to ogg_stream_packetout() after the eos packet. The eos flag pretty clearly applies to the *page* not the packet, so I think how that gets translated into the

HOgg 0.3.0 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the second public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on

HOgg 0.3.0 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the second public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on

HOgg 0.4.1.1 Released --------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the fifth public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly

Here's some instructions for installing hogg on a current Ubuntu 8.10 (or Debian unstable? testing?) system, ie. if you don't already have haskell's cabal system installed: $ sudo apt-get install ghc6 $ wget http://hackage.haskell.org/packages/archive/cabal-install/0.6.0/cabal-install-0.6.0.tar.gz $ tar zxf cabal-install-0.6.0.tar.gz $ cd cabal-install-0.6.0 $ ./bootstrap.sh $ cabal

HOgg 0.2.0 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. http://snapper.kfish.org/~conrad/software/hogg/ This is the initial public release. The focus is on correctness of Ogg parsing and production. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* tools[0],

On 26/02/2008, Ralph Giles <giles@xiph.org> wrote: > On 25-Feb-08, at 3:42 PM, Conrad Parker wrote: > > > ok. If the correct behaviour should be to ignore the incomplete > > packet, that should also be clarified in the spec. > > > Fair enough. What if no packet ends on the eos page? What about > additional pages after the eos page? good point, they've

HOgg 0.4.0 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the third public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on

HOgg 0.4.1 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the fourth public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on

Hi, (I was discussing this with Adam earlier today, and he has also mailed vorbis at xiph.org about this issue in March). This sounds like it needs a new tool specifically for fixing broken Ogg files. Suggestions so far (tried by Adam, or suggested to him in email/IRC): * oggz-sort, hogg sort These rewrite the file, sorting the pages by presentation time. This usually fixes muxing problems,

2008/10/29 Romain Beauxis <toots at rastageeks.org>: > > I am currently implementing theora for our application. > In our model for generating ogg streams, we may want to stop > a stream while not providing a new YUV data buffer for encoding. > > Current API doesn't allow such thing, since the eos flag is set by the > packetout function only when the last_p parameter

>> There general idea with Ogg has been to distinguish non-fatal from >> fatal errors. libogg reports these by returning -1 while still >> returning the next valid bit of data. > > ok, would non-fatal translate into a SHOULD recommendation in the > spec, and fatal translate into a MUST? I assume there there are cases where a MUST isn't respected, yet libogg is

I've studied all the texts I can find. Wine lists Canon EOS Utilities as compatible. I have installed Wine (1.1.44 with 1.2 packet) and it works with Notepad. I'm using Ubuntu 9.10. However, I can't get it to work with Canon EOS Utilities. I tried to follow instructions but to install latest edition of EOS I need to first install the initial CD. The initial CD files won't

I have over 1,000 ogg vorbis files that are no longer playable or editable. I believe the main cause was a MediaMonkey plugin that automatically fetched album art and added it to the header. The plugin itself just uses the generic MediaMonkey metadata facility, but something happened -- perhaps when the album art bitmap image was too large -- that caused the files to no longer work.

On 14/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Ralph wrote: > > Conrad, does this work for the other codecs as well? I vaguely > > remember libvorbis putting -1 on the header packets instead of 0. > > AFAIK, it's 0, -1 being for partial pages, from the ogg docs. -1 (or, I > suppose all negative values, but I'm not sure) mean