search for: grosch

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > Hi, > > > > have I just overseen a link, or is the format description on > > http://flac.sourceforge.net/format.html lacking information on how to > > actually decode the residual partitions to PCM sample data? > > you are correct, it is no...

Hi, have I just overseen a link, or is the format description on http://flac.sourceforge.net/format.html lacking information on how to actually decode the residual partitions to PCM sample data? Tor

--- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > -----Ursprungliche Nachricht----- > > Von: Josh Coalson > > > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > > Hi, > > > > > > have I just overseen a link, or is the format description on > &gt...

Torsdag, 23 januar 2003, skrev Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch- link.de>: >According to the format description, the coding method has to be 0. > >I've been using libFLAC 1.0.4 to encode the stream. I've checked my interpretation against "flac -a" and it seems to read 17 bits for each warmup sample. Here is its output: frame=16...

Torsdag, 23 januar 2003, skrev "Tor-Einar Jarnbjo" <Tor-Einar_Jarnbjo@grosch- link.de>: >- My implementation seems to decode fixed subframes now, but the lpc >subframes contains nothing but noise, and the bitstream is out of sync after >reading one. The source code I'm using for decoding the lpc subframe is >available here: http://user.cs.tu-berlin.de/~...

--- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. > inf.upol.cz>: > > >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is > >17bit number). And warmup samples will be (17 - wasted_bits) bit. > > Voila, this was...

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > Miroslav's suggestion is the best right now. I probably should > hand-craft a stream that exercises a decoder as much as possible. I've already tested my decoder with the options -0 to -8 and it works, but the streams doesn't contain any verbatim or constant subframes. I guess this depends heavily on the input

...t case, it would be proper to play them after eachother. On the other hand, it makes sense to synchronize the streams according to their timestamps (granule position) too, or does this implicitly require a multiplexed (instead of chained) stream? Tor -- Tor-Einar Jarnbjo IT Consultant, Itera Grosch & Link AG Tel.: (0170) 222 54 38 <p><p><p><p>=================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ =================================================================== <p>--- >8 -...

Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. inf.upol.cz>: >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is >17bit number). And warmup samples will be (17 - wasted_bits) bit. Voila, this was the source of all my frustration, sync problems and who knows what. My decoder now works correctly for files encoded with the default settings. Are

Hi, There is something I don't understand about the page_segment and segment_table values in the documentation. As I understand it, the segment table consist of as many bytes as specified in page_segment, PLUS one trailing byte with a value between 0 and 254. I've looked at some files that has a Comment tag so large, that it is spread over two pages. Here, the first Page Header (not the

The IETF passed the application/ogg MIME type some days ago. I couldn't bring you the news earlier because of the MS SQL worm that has been wreaking havoc all over my local networks. The IETF wants some clarifications in Silivias draft for the Ogg stream format, but apart from that I think it will also be passed soon. The RFC and IANA registration of this mimetype will probably be published

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > yes, I will probably get to it soon after the release. > the encoding side is pretty convoluted but for decoding, > src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() > should be pretty straightforward once you ignore the > FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to > ask

Hi, is there an error in the last part of the algorithm describing how to read a floor1 header? According to point 18 and 19, the vector [floor1_class_dimensions] must have at least [floor1_partitions] elements, but when reading/computing these two values on the beginning of the header, they are not related to eachother, and my attempts to apply this algorithm to real ogg-files gives me

Hi, is it somehow possible to locate the start of the first vorbis packet in an ogg page (Px) without reading backwards to find the last "fresh" ogg page and parse the vorbis stream from there until reaching Px? Tor <p><p>=================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/

Torsdag, 10 oktober 2002, skrev du: >On the other hand, it's certainly possible that the published >specification contains errors that need to be addressed. It is not a >monolithic document written in stone. The only way we'll really be able >to sort those issues out is when people try to build stuff from scratch >using the published data, and come across discrepancies.

Torsdag, 10 oktober 2002, skrev du: >Actually, people have implemented perfectly valid Vorbis encoders and >decoders before the specification was even published. I wouldn't go so far >as to call other people on this list dirty liars, but I suspect that the >spec that's published is good enough for them, and they're simply >dealing with different issues than you are,

Fredag, 11 oktober 2002, skrev du: >Rubbish. Been there, done that (multiple times). Look at rehuff, for >example; written without looking at libvorbis (nor at the spec). And you wrote that without any knowledge about the file format? Tor <p><p>=================================================================== EASY and FREE access to your email anywhere:

Hi, just to prevent me from overreading something, I have a question and probably the only possible solution, but I would appreciate if someone could tell me if there is a better solution. I am currently implementing an Ogg demultiplexer for a media API, where the demultiplexer plugin has to provide a static number of logical streams. Adding and removing logical streams as they appear when

Fredag, 3 januar 2003, skrev du: >Ogg has always appeared to me to correspond only to the _track media_ >and _sample_ layers of a QuickTime movie. So you still need to know >what all the CODECs are and how to use them individually to >manipulate what should be general data in the file. Please, somebody >correct me if I'm wrong. I have asked the same questions here on the

Mandag, 2 juni 2003, skrev du: >On Mon, 02 Jun 2003 21:22, Vitaly Nechyos wrote: >This is what people usually want when they say 'normalization'. AFAIK, you >can't easily tinker with the vorbis frames to add a scale factor in the same >way you can with MP3, but I could be wrong. I could be wrong too, but if I haven't overseen anything, it should be possible to