similar to: vorbiscomments in speexenc

Hi, it seems Ogg keeps track of a packet's size at the byte level, rather than at the bit level (eg, if I encode a packet with just one bit, decode will think there are 8 bits available). Am I right ? Not that it's a particularly important issue, since remaining bits will probably be initialized, but I noticed this while adding some calls to oggpack_look1 at the end of my decode routines

Hi, I just added skeleton meta data output support in speexenc. The option is disabled by default and can be enabled using -k or --skeleton. I'm using a very simple skeleton API for handling skeleton packet generation which is contained in skeleton.h & skeleton.c. Please check the patch and whether xine/mplayer/quicktime and other players support the skeleton enabled speex file. At the

Using metaflac (1.0.3) like this: metaflac file.flac --set-vc-field=title=test??????e? The vorbiscomment will not be UTF8-encoded, instead they will be stored directly as ANSI. When trying to add some more comment, it gave the following error: ERROR: writing FLAC file file.flac, error = FLAC__METADATA_CHAIN_STATUS_OK Does that mean that weren't enough room for the comments? But

--- Mattias Dahlberg <mdati00@student.vxu.se> wrote: > Using metaflac (1.0.3) like this: > > metaflac file.flac --set-vc-field=title=testÅÄÖåäöeè > > The vorbiscomment will not be UTF8-encoded, instead > they will be stored directly as ANSI. yes, metaflac is currently not doing utf-8 encoding. the same libutf8 from libvorbis is in the flac source tree but it's not

Hi, I have speex running as a part of a voice conferencing app. Well, one under development anyway. I'm running VBR at quality 3 and get a "hissy-squelchy" background noise. This is fine, kinda, because the internal microphone in the laptop picks up hiss, the sound of the (actually very quiet) hard drive and generally speaking is of less than exemplary quality. To help

I haven't actually had many questions up to now. Despite the all-encompassing CP_INSTANCE monolith, things have been relatively easy going. Now we get into real grit: First off, CBitman looks like it has endianness issues; it's packing into host-order 32 bit arrays (the comments and symbol names seem to indicate that this was originally byte-based packing code that got upped to 32 bit.

Hi, I have done some code cleanup of my speexenc patch for skeleton support. Also a warning message have been added to let the users know that some decoders may fail with skeleton output enabled. The speexdec patch enables speexdec to play skeleton enabled speex file. Thanks in advance for the feedbacks. --tahseen -------------- next part -------------- A non-text attachment was scrubbed...

I am transcoding mp3 to wave using ffmpeg I am then piping it to speexenc for speex encoding but the speex file size is 496 bytes after the command ends https://lists.ubuntu.com/archives/ubuntu-users/2010-March/212927.html https://lists.ubuntu.com/archives/ubuntu-users/2010-March/212949.html https://lists.ubuntu.com/archives/ubuntu-users/2010-March/212954.html what am I doing wrong? bellow is

No, I wasn't having a management lobotomy moment. If the target's registers have no subregisters, SubUsed is false and the assert gets tripped. Ok, back to the original question: What was the original intent in this code (lines 186-193 in lib/CodeGen/RegisterScavenging.cpp)? -scooter On Thu, Feb 25, 2010 at 7:00 PM, Scott Michel <scooter.phd at gmail.com> wrote: > Ugh.

On Sat, 2006-07-15 at 14:35 -0700, Ralph Giles wrote: > On Sat, Jul 15, 2006 at 02:17:22PM -0500, Joe Wreschnig wrote: > > > I'm working on support for tagging Speex files for Mutagen[0] and part > > of the specification at [1] is confusing me. It says the first page > > should have granulepos 0 and packetno 0. Does this really mean page > > sequence number 0,

(Sending again after subscribing, I guess the moderator is on vacation.) I'm working on support for tagging Speex files for Mutagen[0] and part of the specification at [1] is confusing me. It says the first page should have granulepos 0 and packetno 0. Does this really mean page sequence number 0, since the Ogg format doesn't number packets? If it doesn't mean page sequence number,

On 09/02/2008, Ralph Giles <giles@xiph.org> wrote: > Yes, all that is reasonable. The original argument was that we need a > library anyway, no one noticed the function call overhead, and using > libogg simplified the embedding. > > Now, we'd like to remove libogg entirely as a dependency to avoid > confusion when using other containers, but that's an api change...

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

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

Does anyone know of programs one can use to verify the integrity of OGG Vorbis and MP3 files? I've found that Ices 0.3 has a penchant for: 1) skipping files it deems improperly encoded, or 2) passing squelchy aural gibberish on to Icecast and then promptly crashing. The only method I've found is trial and error and Google has been of little help. Thanks! Jed --- >8 ---- List

Ivo Emanuel Gon?alves wrote: > And IF that kind of performance can be gained in libvorbis too, the > question is, what are we waiting for? I doubt the performance gain would be that large. Theora had the fun little situation where it was thunking into the big endian version of some bitpacker functions which were one-line calls to the little endian version. Because gcc seemed to be

Hello, I have problems to compile speexenc 1.1.4, ihave the following errors <p>speexenc.obj : error LNK2001: unresolved external symbol _speex_preprocess speexenc.obj : error LNK2001: unresolved external symbol _speex_preprocess_ctl speexenc.obj : error LNK2001: unresolved external symbol _speex_preprocess_state_init Debug/speexenc.exe : fatal error LNK1120: 3 unresolved externals Error

Hi all, Been trying to compile speex 1.1.10's speexenc for win32 using Visual C++ 6.0 but came up with some errors (abt 33 of them, syntax errors). I just traced them to a variable called "SPEEX_VERSION" which i think isnt defined in speexenc but rather defined in misc.h, which wasnt one of the include files in speexenc... should i add a line that includes misc.h in speexenc? i

Hi. Le duodi 2 frimaire, an CCXIV, Wesley J. Landaker a ?crit?: > speexenc always crashes on amd64; here is an example, and lots of info: I tracked this bug a bit further than you. Here is the origin of the crash: op.packet = (unsigned char *)speex_header_to_packet(&header, (int*)&(op.bytes)); (from speexenc.c) op.bytes is a long, not an int, it is wrong to pass it as an int,

Hi Mon, I added 'misc.h' to the #includes in speexenc.c and commented out the declaration of 'le_int' in 'wav_io.h'. Then, it compiles and works fine. John Mo Win wrote: > Hi all, > > Been trying to compile speex 1.1.10's speexenc for win32 using Visual > C++ 6.0 but came up with some errors (abt 33 of them, syntax errors). I > just traced them to