similar to: Web-based forum for Vorbis discussion

And thats only a player. What about an (Open Source) encoder? Nah, I'll stick with OGG for the time being. Regards, Mark -- Mark de Bokx Internet Service Engineer ICT Communication and Media Services PlanetMediaGroup the Netherlands "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty not safety." --Benjamin Franklin

Hi all, I started testing the RC1 encoder at ftp://sjeng.sourceforge.net/pub/sjeng/oggdrop.exe (based on branch_monty_20010708) On the songs I have tested so far (not much :) I did not hear any stereo issues, but there are some very noticeable problems with the produced files. Songs without much high-end will suddenly have one when encoded. (you'd expect it the other way around) It

I would very much like a lowpass option because for FM radio broadcasting I don't want to encode frequencies above 15khz. I'm waiting for this option before switching to ogg from mp3(lame). Ross. > -----Original Message----- > From: owner-vorbis@xiph.org [mailto:owner-vorbis@xiph.org]On Behalf Of > Gian-Carlo Pascutto > Sent: Tuesday, 4 September 2001 01:46 > To:

Hi! I am very pleased with the progress that Ogg is making, expecially after I read the latest comparision tests on http://ff123.net/128test/instruct.html that put OGG on top aside with MPC. BUT the APPLAUD.WAV test case ( http://lame.sourceforge.net/download/samples/applaud.wav ) still produces **VERY** easily audible high-frequency artifacts when encoded with OGG RC3 up to q4.9 (!!!). Things

Hello all, I'm glad to announce to you that Vorbis now has full ReplayGain support. If you're not familiar with ReplayGain, take a look at www.replaygain.org. The main features are: a) all songs play back with equal loudness b) removes the need for normalization c) allows for clipping prevention Using it is very simple. Get a compatible decoder (ogg123, XMMS and WinAmp all support it

Hi all, I have implemented ReplayGain support for Vorbis. If you are not familiar with it, it is basically a method of making sure all your files have equal loudness, remove the need for normalization and prevent clipping during playback. The process is totally lossless, and supporting it requires minimal work. More info about the exact workings can be found on www.replaygain.org (recommended

After doing an informal (128k) listening test, I have concluded that I prefer Beta4 over RC2. The 16kHz low-pass on the RC2 encoder makes it sound like FM radio. Both encoders SEEM to have a couple of dB bump at 10kHz. JT --- >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

Hi all, ome people asked if it was possible to make an even higher quality mode by incorporating some of the changes from the first tuned version into the 350kbps mode. I did so and made a new version with this new mode. It gives bitrates from roughly 300-350kbps. That's a lot, but it also gets very hard to find something it artifacts on :) Should be sufficient for archival quality. In

A large group 64kbps listening test has just come to an end, organised through the Hydrogenaudio[1] audio discussion board (and managed expertly by Roberto Amorim). Eight codecs were tested on twelve different samples, designed to cover a wide range of musical genres. The codecs tested were[2]: * Ahead/Nero 6.0.0.15 HE AAC VBR profile Streaming * Ogg Vorbis post-1.0 CVS -q 0 * MP3pro (from

Hello -- I desperately want to start using Ogg compression on music I release on the internet, but I am encountering a fair amount of artifacts. I noticed some in beta4 and was hoping they would disappear with RC1. However, I've been playing with RC2 and I've still been banging my head into a number of problems. A majority of the music I make has long drones with a fair amount of spectral

As far as I can see, transcoding could be usefull for people who do not primarly care about quality but about filesizes. One could assume that such a user would have a collection of mp3's at 128kbps or higher bitrates, and uses an encoder like BladeEnc or Xing. He wants to take uses of ogg's supposed quality and transcode his 128-or-higher files into 96 or 112kbps oggs to save diskspace.

In case you missed it, RC2 is on slashdot.org too: http://slashdot.org/article.pl?sid=01/08/13/1811241 BTW Gian-Carlo Pascutto wrote on /. that RC3 should appear very soon (in a week or so)? Also, it looks like Wall Street Journal article is not available on-line (at least to non-registered persons). If someone is registered or have a paper edition, please post this article somewhere so that we

---------- > Van: ORK <korsmo@solungen.hm.no> > Aan: vorbis@xiph.org > Onderwerp: [vorbis] OggEnc help file > Datum: maandag 3 september 2001 18:21 > > Somebody asked how to use OggEnc a while ago. > > OggEnc v0.8 (libvorbis rc2) > (c) 2001 Michael Smith <msmith@labyrinth.net.au) > > Usage: oggenc [options] input.wav [...] LOL! --- >8 ---- List

>No big deal. I thought someone might be interested in a bug report. I >guess not. Your report is very much appreciated. Thanks! I hope the fixed version works for you. Hint to other posters: It never hurts to check the facts before wildly speculating and preaching about shells and operating systems. Thank you. -- GCP <p>--- >8 ---- List archives:

When using the abx utility that is in LAME's misc dir, trying it on an ogg (with ogg123) gives the following output: Standard Open Source Bug detected, try murksaround ... (ogg123 is decoding to stdout) IIRC this also happened with older mpg123's but no longer with the latest release. Latest ogg123 from CVS still gives it though. Someone stole code but forgot to check for fixes? :)

Yes, r3mix found a bug, no it's not a serious one. It's amazing how something small gets overblown like this. The r3mix reviewer basically just hit the known short block trigger bug when doing his tests. We've known about this bug since before the beta and haven't fixed it yet because it was considered relatively minor; [ironically] it mostly affects test samples with a single

Hi everyone, Recently I made an attempt at merging the tunings of GT3b1 into the official Xiph.org 1.0.1 libvorbis code. While 99% of the GT3b1 tunings are independent of 1.0.1, there is one particular value (_psy_noiseguards) which affects the whole quality range. I've chosen to use the 1.0.1 values since they changed since 1.0. Therefore, files encoded in GT3b1 mode (q 5 and above)

Hi Roger, I'm using Samba as AD DC in version 4.5.0 on Centos 7 with Bind9_DLZ DNS backend, Bind is 9.9.4 and I don't have that issue. I tried reload my bind using systemctl at first and no issue, then I tried "rdnc reload" to be sure rndc was used, still no issue. By no issue I don't mean log are clean, I mean the DNS service is working well (tested using dig commands).

I've added logs (dirty and quickly): logging { channel "request" { file "/var/named/named.run" size 10m; print-time yes; print-category yes; severity debug; }; category default { request; }; category security { request; }; }; Reload DNS service using systemctl once, twice, then restart Bind, reload it using rndc and no complain about log file and

Hi guys, I'm facing a problems with samba4 + bind9_dlz that consuming my time for several days. Everything is working fine until samba4 need to update dns when I'm work with more than one DC server. When samba (or bind) need to reload all zones, the module bind9_dlz is shutting down and then all my environment stops and I need to restart the bind to up again. See my log: ... Jan