foo_abx 1.3.4 reportfoobar2000 v1.1.7 beta 12011/05/05 20:12:50File A: E:\music\modules\buzz_rtltune.XMFile B: C:\Users\mud\Desktop\buzz - RTL.tune001 .ogg20:12:50 : Test started.20:13:18 : 00/01 100.0%20:13:31 : 01/02 75.0%20:14:32 : 02/03 50.0%20:14:57 : 03/04 31.3%20:15:47 : 04/05 18.8%20:16:06 : 05/06 10.9%20:17:49 : 06/07 6.3%20:18:00 : 07/08 3.5%20:18:07 : 08/09 2.0%20:18:20 : 09/10 1.1%20:18:27 : 10/11 0.6%20:19:02 : 11/12 0.3%20:19:09 : 12/13 0.2%20:19:17 : 13/14 0.1%20:19:25 : 14/15 0.0%20:19:33 : 15/16 0.0%20:19:46 : 16/17 0.0%20:20:04 : 17/18 0.0%20:20:12 : 18/19 0.0%20:20:20 : 19/20 0.0%20:20:27 : 20/21 0.0%20:20:30 : Test finished. ---------- Total: 20/21 (0.0%)
Sorry for looking like a tool for asking this, but with support for up to 500kb/s bitrate for music, does that mean that CELT/Opus is also going to be positioned into regular audio-to-file encoding like MP3 and AAC?
I'm hoping that Opus will be used more widely as a VoIP codec (since low latency necessarily means compromising coding efficiency anyway), and that xiph's new brainchild Ghost will be what replaces Vorbis for music archival. So I'd be more okay with Ghost getting the multichannel support over Opus, so long as Ghost comes along, that is.
a couple days ago, I compiled opusenc/opusdec, and apparently they plan multichannel for Opus. I thought this because of the --bitrate option being "6-256 per-channel". more on target, commit 6dd8086d in users/greg/opus-tools.git says "First cut at working multichannel support".
could it be that "multichannel" means no more than stereo? I've never heard them speak of something beyond...
--downmix-stereo Downmix to to stereo (if >2 channels)
--speech Optimize for speech--music Optimize for music
Quote from: Speckmade on 27 November, 2011, 09:11:43 PMcould it be that "multichannel" means no more than stereo?no.
could it be that "multichannel" means no more than stereo?
Opus is what we've got, and it's damn good. The compromised quality is speculation - look at the facts: The prototypes clearly beat HE-AAC, less complexity and more efficiency than Vorbis, competitive on a much broader bitrate range, official recommendation as an internet standard, probably it'll also be endorsed by the ITU - and on top of all that the super-low latency, specialised speech mode built-in - what else could I wish for? Also, you can kind of "turn off" the low latency: Have you noticed that you can turn up the block size to almost 60 ms?..
Given the VoIP background, where monaural audio is still predominant, could it be that "multichannel" means no more than stereo? I've never heard them speak of something beyond...
So, I would like to know if the IEFT specification was tested. That is: if someone has tried to write at least a decoder based on it.
I saw the IETF draft, and, as expected, the final word on the specification will be reference implementation itself. I suppose that it means that, like VP8 and others, any bug or quirky platform dependent behavior in the reference implementation will become the standard itself. This is specially worrying because SILK was closed source for a long time.
So, I would like to know if the IEFT specification was tested. That is: if someone has tried to write at least a decoder based on it. I haven't found any other opus implementation besides the reference one. You guys maybe should talk with ffmpeg/libav people, that will probably write their own opus implementation sooner or latter anyway, to do that. They may even give some useful advice on the codec specification.
And is there any plans for an "Opus-HD" (high delay) in the future? Or the low-delay design is too fundamental to the codec design, and some additional bigger window overlaps and frame sizes will be too difficult to implement/not make enough difference? I guess that with the economy in signaling bits, there is no bits left to extend the codec... right?
The presentation from IETF 82 covers many of the things we did for testing, specifically with these concerns in mind http://www.ietf.org/proceedings/82/slides/codec-4.pdf
CELT/OPUS has been designed before 2/06/12 and I'm curious does it have any advantages over iSAC?