similar to: Vorbis beta 3 ...

Ross Levis <ross@soulfm.cjb.net> wrote: > and submitted which show up problems in the LAME encoder. I thought > Velvet.wav was on the list but I just checked and couldn't find it so I > presume LAME has fixed the problem. I guess Monty has gone through the You can get velvet.wav from here: http://r3mix.50g.com/velvet.zip (2MB) Greetings, Aleksandar --- >8 ---- List

Check this out: http://7amnews.com/2001/features/032101.shtml Greetings, Aleksandar --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list

I noticed that clipping occurs in lossy audio compression even if there is no clipping in the original file (though the original file has peaks that are just below the maximum). I know that this happens due to all the filtering involved during compression, but I'm wondering just how audible this clipping is because I don't hear anything wrong. I mean, as things are now, is it safe to say

During the interesting interview that binaryfreedom has made with Monty and Jack, Monty mentions cascading, a feature that will be added, quote: "Cascading is the ability to make multiple passes through the frequency spectrum, iteratively filling in more detail, like a progressive jpeg". What are the advantages of something like this - does this generally improves quality or is it used

I would like is someone could give me a few hints on how to distinguish whether a WAV file is uncompressed or it was created by decompressing mp3 file - I usually could take a look at the file through Sound Forge and look if there is a freq. cut-off (usually above 16kHz) or if there isn't one - then I can easily tell by listening if there are high-frequency artifacts (common for mp3). Is there

I tested Vorbis encoder - beta3 version, and here are my thoughts: - In comparison to beta2, subtle high-frequency artifacts seem to be gone (though they were small in beta2). Good job there! :-) - Velvet.wav also sounds better, but transparent quality is reached at -b256+. - Horn.wav still sounds very sucky, mode -b256 gives ~100kbps (this is understandable because in this sample practically

Not related to Vorbis, but it shows how software patents can be abused to the point where it becomes absurd... http://www.idg.net/ic_316584_1794_1-483.html BTW I used a hyperlink here... BT can sue me... ;-) Greetings, Aleksandar --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to

Frank Klemm made the clip to test short block switching - it's made of series of short periodical 'pulses', and this period gets smaller as time passes. You can get this file at: http://www.uni-jena.de/~pfk/Short_Block_Test.wav.gz.gz (1.6MB) (uncompress it twice with gzip) I used oggenc beta3 & mp+ 1.7.8 Oggenc gave 160kbps using mode -b 256 mp+ gave 350kbps (using

While using ogginfo (command line util), I've noticed that there's info on "stream integrity" (it says stream integrity=pass). Does this mean that there are no errors in the bitstream (which can happen if the file is corrupted)? <p>Aleksandar <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

Hello everyone, ff123 compiled Monty's branch of the RC1 encoder, see his post on r3mix.net forum: http://66.96.216.160/cgi-bin/YaBB.pl?board=c&action=display&num=994299736&start=30 Anyway it only supports ~128kbps mode, so I did a quick listening test with some files that bugged vorbis beta4. grace.wav - the right channel is still a bit watery, and I think this can be seen

Comments? ---------------------------------------- "Mark Taylor" <mt@sulaco.org> wrote: [...] > This is related to one minor objection I have to vector quantization > based codecs like Vorbis and the MPEG4 VQ codec: they do not compute > the quantization noise during the encoding process. The choice of > codebooks (use a big codebook: low quantization noise, use a

Hi everyone. Reading all this posts about patent issues, I thought of something: if, by some wild chance FhG (or some other audio company) manages to prove in court that vorbis is breaking their patent rights, you could do something like LAME developers did: release only source code and let people do the compiling so that only users that are living in countries where patents on algorithms are

Hi everyone. Reading all this posts about patent issues, I thought of something: if, by some wild chance FhG (or some other audio company) manages to prove in court that vorbis is breaking their patent rights, you could do something like LAME developers did: release only source code and let people do the compiling so that only users that are living in countries where patents on algorithms are

Check this clip (it's small, 373kb) http://www.geocities.com/jdxss/udialwav.zip It left oggenc, lame and MP+ encoders choking in dust. -- Vorbis Xtreme | http://solair.eunet.yu/~aldov/ Ogg Vorbis is the free, open source alternative to MP3 --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a

I''ve upgraded to Rails 1.1.2, and I''m trying to push this change through to our build server (Linux/Oracle) and we are getting some errors in the unit tests using Oracle. Looking at the data in the tests reveals a precision problem. Looking at the tables tells the whole story. My development database contains this table: SQL> describe dls_grids; Name

Okey dokey. I'll start setting things up. I think what I'll do is start with 1.1 (or the infamous and soon-to-be-released 1.2 :). Once that works, I'll probably put together a CVS snapshot version. I know LLVM currently supports ia32 and SPARC; is anyone looking at any other architectures? On Sun, 2004-03-07 at 17:30, Chris Lattner wrote: > On Sun, 7 Mar 2004, Al Stone wrote:

Hi. Since I'm new to this mailing list, I don't know whether this was discussed in this mailing list, or if it is already fixed. Anyway, the problem is that all audio encoders out there add a small amount of silence to the start/end of the encoded file. This is usually a small amount, around 0.03 seconds. Most of the time it goes unnoticed, BUT when you have tracks that flow into one

We all know that currently Vorbis is the only codec out there that doesn't add any silence to the decoded file, so when you decode your .ogg file the resulting .wav will be exactly the same length as the original one. This is very useful when encoding gapless songs (like live concerts...). But since Vorbis is a lossy codec, even though there is no silence added, sometimes you can still hear a

Monkey's Audio lossless compressor (currently win32 only, free but not open-source except decoder) author is thinking to implement a kind of audiophile-quality lossy compression which would filter "noise bits" that are hard to encode lossless but which are (or should be) inaudible and thus improve lossless compression (avg. 300-450kbps). I think that implementing something like this

Hi Mr Tierney, I have noticed an error message from R 1.12.x's CMD check for a while (apparently prof Ripley completely rewrote CMD check in R 1.12+) e.g.: http://bioconductor.org/checkResults/2.7/bioc-LATEST/snpMatrix/lamb2-checksrc.html ---------------- * checking R code for possible problems ... NOTE Warning: non-unique value when setting 'row.names': ?new? Error in