similar to: liboggz release

Hello Silvia, ok Enviado do meu iPhone Em 22 de jul de 2018, à(s) 19:02, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> escreveu: > Hey Henrique, > > I think liboggz needs a new maintainer. Are you volunteering? > > Cheers, > Silvia. > > >> On Mon., 23 Jul. 2018, 6:47 am Henrique Almeida, <hdante at gmail.com> wrote: >> Hello, there are

So, do I have to sign anything ? Enviado do meu iPhone Em 23 de jul de 2018, à(s) 12:36, Henrique Almeida <hdante at gmail.com> escreveu: > Hello Silvia, ok > > Enviado do meu iPhone > > Em 22 de jul de 2018, à(s) 19:02, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> escreveu: > >> Hey Henrique, >> >> I think liboggz needs a new maintainer.

Henrique Almeida wrote: > So, do I have to sign anything ? No. We're currently discussing how to actually do this in #xiph on freenode. Most Xiph projects have migrated to <https://gitlab.xiph.org/>, but not liboggz, which means it's not a simple matter of making you a Gitlab account with the appropriate permissions. Feel free to join us there. Also CCing TD-Linux who may be

Quite a while ago, the specification was modified to change the way the nondefault scan format was signalled; this patch fixes that. Index: liboggz/dirac.c =================================================================== --- liboggz/dirac.c (revision 3759) +++ liboggz/dirac.c (working copy) @@ -122,6 +122,10 @@ 1, 9, 10, 9, 10, 9, 10, 4, 3, 7, 6, 4, 3, 7, 6, 2, 2, 7, 6, 7, 6, }; +

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

It seems there still isn't a tool (at least not a Xiph one) for modifying Opus comments from the command line. I've had a go at adding support in liboggz (which is fairly trivial, since it just means adding recognition for the Opus stream). That certainly works for comment editing, but I'm not sure if it's is good enough to commit back, because timing gets reported back slightly

It seems there still isn't a tool (at least not a Xiph one) for modifying Opus comments from the command line. I've had a go at adding support in liboggz (which is fairly trivial, since it just means adding recognition for the Opus stream). That certainly works for comment editing, but I'm not sure if it's is good enough to commit back, because timing gets reported back slightly

A widely used platform doesn't bother to have C99 integer types, so this allows building with it. Reported by sirlemonhead on IRC. Index: src/tools/oggz_tools.c =================================================================== --- src/tools/oggz_tools.c (revision 3827) +++ src/tools/oggz_tools.c (working copy) @@ -450,7 +450,7 @@ dg->pt = (iframe + pframe) >> 9;

Hi, this patch adds dirac.c as a source file to the oggz tools, rather than a lib. The previous would try to compile at link time, and would not include the right -I flags, and this will fail when including config.h in dirac.c (which will be needed when someone else posts a patch to get liboggz to build on win32). I'm not toally sure why dirac.c isn't just in the sources in liboggz rather

This is a patch to the latest SVN trunk of liboggz to allow compilation of the library on win32 using Visual Studio 2003 and 2005. The project files have been updated to fix previous errors with compiling using both of these IDEs. Should work fine but please let me know if they don't work for you :) -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I intend to use Ogg+Speex for voice recording/playback in a VoIP app. I am experimenting with liboggz to get acquainted with its API. As test files I am using some Ogg-Speex files converted from WAV files with speexenc.exe. I wrote a little testing app in Visual Studio 2010 under Windows 7. I defined OggzReadPage and OggzReadPacket callbacks with oggz_set_read_page()

On 31 December 2016 at 14:03, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Ian Malone wrote: >> >> out, due to the Opus pre-seek, I think. Fixing that probably requires >> adding an Opus-specific metric to liboggz, since the current default >> linear one doesn't deal with first granule position being set. Thought >> I'd check before getting

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-liboggz-libfishsound.html Thanks to Ralph Giles

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-liboggz-libfishsound.html Thanks to Ralph Giles

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-liboggz-libfishsound.html Thanks to Ralph Giles

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-liboggz-libfishsound.html Thanks to Ralph Giles

Hi, I'd support the view of freezing the main header, since it helps in actually getting some implementation happening and it seems fully agreed on by everyone. FAIK, Zen has already started an implementation and if you, Conrad, implement, too, there is enough code to do validation. What do you expect now to make it an "officially frozen" specification? Publish it on the main

> any new fields. However, I cannot even find Dirac in oggz > http://git.xiph.org/?p=liboggz.git;a=blob;f=src/liboggz/oggz_auto.h; There's dirac.[ch] in the tools directory, though I haven't looked at what's in there. Not sure why it's segregated like that.

On Fri, Jun 5, 2009 at 4:30 AM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > It holds the granulerate, so it'd allow this for those codecs that use the > granule shift way of encoding their granules (except for those pages > where no packet ends, as these will have no granpos set). BTW, we need to add another field out of the remaining reserved bits

> Since these are the only two uses of int64_t instead of ogg_int64_t in > liboggz, please commit. In svn. Didn't get the OK from Conrad from committing to his software, hope it's OK kfish ^_^