similar to: Re: Ogg Spec, etc.

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=168 blocksize=4608

Fredag, 31 januar 2003, skrev du: <p>>Next thing is, that I would like to clarify the difference between a codec's >latency (which I would die to know in exact figures for the vorbis codec one >day - as well as block sizes, but that's another story) and the (bandwidth) >"smoothing window" latency - call it buffering or whatever. One thing is the codec

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

> -----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

Hi all, Yes, it's true. A new version of rehuff, the tool that losslessly compresses Vorbis files: one that is easy to compile, and that works with newer-than-two-years-ago streams, too! On 1.0 streams, you get about 3% size reduction, and the headers get _much_ smaller (which helps for fast-start network streams). Building it should be easy (you might have to add some -I and -L for

Hi all, Yes, it's true. A new version of rehuff, the tool that losslessly compresses Vorbis files: one that is easy to compile, and that works with newer-than-two-years-ago streams, too! On 1.0 streams, you get about 3% size reduction, and the headers get _much_ smaller (which helps for fast-start network streams). Building it should be easy (you might have to add some -I and -L for

Hiya, Here is the sources to my "rehuff" program. ./rehuff in.ogg out.ogg does a lossless recoding of a vorbis stream. (It generates optimal huffman codes for the particular stream). This code is meant for developers only, until someone is kind enough to provide good build and configure support for it. I won't. And no installation help questions please. There is a little patch

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

Hi! I don't find any detailed information about this in the specification, so I try a question here. If two plain, unmultiplexed Ogg/Vorbis-files are chained into one file, you end up with an Ogg-file with two logical Vorbis streams. When playing this file, would it be correct for a decoder to synchronize the two streams according to the granule position of the Ogg pages (playing them

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:

> -----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

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

Salve, Imagine ogg vorbis is used to produce radio with free software. A journalist would produce a report end send it with 24kBit/s out from a cricis place somewhere in the world. DRM is going to use MP4 - so his report has to be reconverted with loosing quality :-( Can you imagine to have an free codec someday that would work in embedded radio-reciver like MP4? If yes, should DRM not be open

Hi, I am trying to implement a Vorbis decoder in Java, and I have some problems understanding the file-format specification included with libvorbis. In the header description, there are a few obvious mistakes, which I believe to have solved, but when I try to decode the audio packets, the decoded floor and residue data doesn't seem to make sense at all, and after a few packets, my decoder

What for OS is the server and windows clients? The VPN tunnel, are you lowering MTU sizes? Something like: -A FORWARD -m policy --pol ipsec --dir in -s 192.168.0.0/24 -o eth1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 On the client PC's, have you checkout the windows firewall and are you allowing the remote subnets. The samba server on 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

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

Hi there In the past, i have used lame to encode high quality mp3-files (vbr 1, bitrate ~ 192kbit). I tend to switch to ogg with Quality 4 or 5, but i noticed, that many ogg-files tend to produce too much high frequencies response. In many cases, this is very noticeable. For my opinion, i cannot accept this worse frequence reponse. I have used latest version of ogg (OggEnc v1.0, precompiled

Hi there In the past, i have used lame to encode high quality mp3-files (vbr 1, bitrate ~ 192kbit). I tend to switch to ogg with Quality 4 or 5, but i noticed, that many ogg-files tend to produce too much high frequencies response. In many cases, this is very noticeable. For my opinion, i cannot accept this worse frequence reponse. I have used latest version of ogg (OggEnc v1.0, precompiled

> -----Original Message----- > From: samba <samba-bounces at lists.samba.org> On Behalf Of Rowland penny via > samba > Sent: fredag 30. august 2019 09:57 > To: samba at lists.samba.org > Subject: Re: [Samba] no DNS functionality on second subnet > > On 30/08/2019 07:00, Andreas Habel via samba wrote: > > -----Original Message----- > > From: samba