IETF Opus codec now ready for testing, That's CELT 0.11 Options

[NullC]

Cannot open output: No such file or directory[/code]

I got a little too aggressive with some error handling I added. In any case, fixed and zip file updated.

[IgorC]

Opus, AoTuV and Apple AAC at ~ 128 kbps http://d.hatena.ne.jp/kamedo2/20120603

Also he has tested Opus 0.9.10 (main branch). Newer exp4 branch should do better.

This post has been edited by IgorC: Jun 3 2012, 18:59

[bawjaws]

I notice the previous blog entry was them testing at 80kbps a couple of months ago:

http://d.hatena.ne.jp/kamedo2/20120315/1331839849


I notice he uses tvbr for that one and cvbr for 128kbps. I originally thought this was hobbling iTunes by forcing it to be closer to the target bitrate. I thought this might be compensating for the lack of tuning for VBR in this version of Opus. But reading the docs it seems to actually put a *lower* limit of 128kbps on the encoder, which could be considered a benefit for iTunes, and perhaps explains why it's average bitrate is the highest of the three in that test (it's the lowest in the 80kbps test).

[darkbyte]

Is somebody working on a foobar decoder plugin for Opus? I'm aware of a CELT plugin but i'm pretty sure that it will not work with the new bitstream. I like to test it longer with more samples but i don't wan't to decode back to WAV or use the command line decoder for playback.

This post has been edited by darkbyte: Jun 5 2012, 16:03

[greensdrive]

not sure if this is a bug or if it's meant to be, but the current opus-tools ("current" meaning the latest downloadable from people.xiph.org) does not accept piped input. at least, not in foobar2000. I had to use the %s for temporary file input instead. and I'm referring specifically to opusenc.exe...

also, I second the motion for a foobar2000 decoder, but I'm sure it will be available when opus is stable anyway.

[NullC]

not sure if this is a bug or if it's meant to be, but the current opus-tools ("current" meaning the latest downloadable from people.xiph.org) does not accept piped input. at least, not in foobar2000. I had to use the %s for temporary file input instead. and I'm referring specifically to opusenc.exe...

also, I second the motion for a foobar2000 decoder, but I'm sure it will be available when opus is stable anyway.

It _should_ accept piped input and does when run in wine. It automatically ignores the wav length. Is it crashing for you or just giving truncated files?

A foobar2000 decoder won't be available no one creates one. I'm not aware of anyone working on it. I'd be glad to answer questions / review code to help make that happen. Anyone who works on it should make sure it plays the testvectors at http://people.xiph.org/~greg/opus_testvectors/ (will be posted on the opus site when the set of tests are complete)

[lvqcl]

I have a question about setup_resample() function. It has the following code:

CODE

    opt->skip+=speex_resampler_get_output_latency(rs->resampler);

Maybe it's better to replace it with speex_resampler_skip_zeros(rs->resampler) ?

[NullC]

I have a question about setup_resample() function. It has the following code:
Maybe it's better to replace it with speex_resampler_skip_zeros(rs->resampler) ?

I'd rather not. Why do you ask?

[lvqcl]

get_output_latency() returns rounded value...

For example, if filt_len==128, in_rate==44100 and out_rate==48000 (num_rate=147, den_rate=160):

input latency = filt_len / 2 = 64 samples.
output latency = (filt_len/2)*den_rate/num_rate = 64*160/147 = 69,65986... => 70 samples.

Maybe I'm wrong but IMHO this is the reason of this sub-sample shift (upper part: source, lower - after encoding):



not a big problem, but if it can be easily avoided - why not?

This post has been edited by lvqcl: Jun 11 2012, 17:28

[NullC]

get_output_latency() returns rounded value...
[...]
not a big problem, but if it can be easily avoided - why not?

Well, it can't /generally/ be avoided— because it assumes that the encoder and decoder are using the exact same resampling filter (well, at least one with the matching subsample group delays). Though indeed, it sounds like making input_latency truncate instead of rounding would make it match in opus-tools. Have you tried that? Because it's not possible to avoid a subsample delay in the general case I haven't cared much about it, but I agree if it can be trivially fixed without hurting anything else then why not.

As far as skipping zeros go, I plan on eventually making it so that opusenc can have either reverse extrapolated audio or audio from the prior track in the preskip for improved gapless behavior, and having the preskip differ from file to file is the only way to be sure that people implementing opus playback will bother reading it instead of hard coding some incorrect value.

This post has been edited by NullC: Jun 11 2012, 19:09

[greensdrive]

this first one doesn't work (I put --vbr just to make sure). gives me a 21 kilobyte file. it plays back in opusdec.exe, but is truncated.

CODE

--bitrate 512 --music --vbr - %d

this last one works. plays back the entire file in opusdec.exe...

CODE

--bitrate 512 --music --vbr %s %d

I don't think it's a fb2k bug, but just in case you're wondering, it's foobar2000 1.1.13. also, the original file is wavpack, not wav.

[NullC]

this first one doesn't work (I put --vbr just to make sure). gives me a 21 kilobyte file. it plays back in opusdec.exe, but is truncated.

How long is it? 21kilobytes sounds like it's not being truncated at zero. If foobar is sending some short but non-zero length that stinks and foobar should be fixed. I will add an option to ignore the length but it really shouldn't be needed. (I note that oggenc has an ignorelength option which is not actually connected to anything)

This post has been edited by NullC: Jun 11 2012, 21:16

[kode54]

foobar2000 sends 0xFFFFFFFF for the length fields it cannot predict.

[greensdrive]

How long is it?

this is the opusinfo.exe output:

CODE

Processing file "10 love in plaster.opus"...

New logical stream (#1, serial: 000063ed): type opus
Encoded with libopus 0.9.11-75-gc64f4a4
User comments section follows...
        ENCODER=opusenc from opus-tools 0.1.0-9-gac7490c

Opus stream 1:
        Pre-skip: 356
        Playback gain: 0dB
        Channels: 2
        Original sample rate: 44100Hz
        Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
        Page duration:    360.0ms (max),  360.0ms (avg),  360.0ms (min)
        Total data length: 21536 bytes (overhead: 1.37%)
        Playback length: 0m:00.348s
        Average bitrate: 494.6 kb/s, w/o overhead: 487.9 kb/s
Logical stream 1 ended

please note that the encoder version string may not have been updated with the recent release, as well as any other version string. I am pretty sure that the README says something different as far as what git revision it was built from.

This post has been edited by greensdrive: Jun 12 2012, 04:03

[NullC]

Playback length: 0m:00.348s
please note that the encoder version string may not have been updated with the recent release, as well as any other version string. I am pretty sure that the README says something different as far as what git revision it was built from.

The only explanation I can come up with for that length is that Windows is returning a length of 16384 on a pipe. Weird. I added an --ignorelength before it was pointed out what foobar sends, didn't bother mentioning it because since foobar is sending 0xFFFFFFFF it won't do anything. I'll make it also avoid trying to ftell to get the length and we'll see if that fixes it.

As far as the versions— they're automatically generated from the SCM and don't need to be updated, so they're always correct.

Here is an updated opus-tools that might(?!) fix that behavior if you provide the --ignorelength argument: https://people.xiph.org/~greg/opus-tools.zip

[greensdrive]

--ignorelength works like a charm.

[NullC]

--ignorelength works like a charm.

With this information in hand I went and googled a bit harder— apparently fseek() on Windows returns 0 on pipes (it looks successful). I've added an additional test on Windows to check for pipes and ignorelength shouldn't be needed in these cases anymore. It's still available for use just in case the wav header is wrong in a way opusenc doesn't detect.

https://people.xiph.org/~greg/opus-tools.zip

[greensdrive]

wow. no --ignorelength. no %s. opusenc.exe now works with piped input.

[NullC]

Just a minor update: The win32 builds of opus-tools are now available at http://opus-codec.org/downloads/

Thanks to everyone here in helping it to a maturity level high enough to justify putting it on the site.

I also have some silly live streams running at

http://ec2-50-112-77-171.us-west-2.compute...poralfugue.opus
and
http://ec2-50-112-77-171.us-west-2.compute...8000/clock.opus

If you have curl you can play them using curl URL | opusdec - or with Firefox nightly (after going to about:config and enabling opus).

[greensdrive]

NullC:

not directly related to opus, but it seems the links for the man pages are wrong.

encode goes to opusenc.html
inspect goes to opusdec.html
decode goes to opusinfo.html

those links are part of the sentence: "Opus-tools provides command-line utilities to encode, inspect, and decode .opus files."

figured I'd post it here since I've heard no one can create a Trac account for posting bugs on xiph.org.

[NullC]

NullC:

not directly related to opus, but it seems the links for the man pages are wrong.
figured I'd post it here since I've heard no one can create a Trac account for posting bugs on xiph.org.

Doh. Thanks. Fixed.

We'll have a proper bug-tracker and such up at least in time for the 1.0 release.

[Brazil2]

Before I run anything, can you explain me why the encoder and decoder have gained about 1MB between the latest test version and the v0.1.2 within few hours ?

CODE

File        Date/Time           Size

opusenc     12/06/2012 10:58    329 728
opusdec     12/06/2012 10:58    310 784

opusenc     12/06/2012 14:24    1 348 000
opusdec     12/06/2012 14:24    1 282 881

This post has been edited by Brazil2: Jun 15 2012, 09:55

[NullC]

Before I run anything, can you explain me why the encoder and decoder have gained about 1MB between the latest test version and the v0.1.2 within few hours ?

The Mozilla folks apparently didn't strip the binaries (and they're big to begin with because they're statically linked), stripping removes debugging information and other not terribly essential stuff.

[gmaxwell@helmholtz tmp]$ wget https://ftp.mozilla.org/pub/mozilla.org/opu...tools-0.1.2.zip
[gmaxwell@helmholtz tmp]$ unzip opus-tools-0.1.2.zip
[gmaxwell@helmholtz tmp]$ cd opus-tools-0.1.2/
[gmaxwell@helmholtz opus-tools-0.1.2]$ mingw-strip *.exe
[gmaxwell@helmholtz opus-tools-0.1.2]$ ls -l *.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 287744 Jun 15 16:10 opusdec.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 327680 Jun 15 16:10 opusenc.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 34304 Jun 15 16:10 opusinfo.exe

This post has been edited by NullC: Jun 15 2012, 21:14

[Brazil2]

The Mozilla folks apparently didn't strip the binaries (and they're big to begin with because they're statically linked), stripping removes debugging information and other not terribly essential stuff.

[gmaxwell@helmholtz opus-tools-0.1.2]$ mingw-strip *.exe
[gmaxwell@helmholtz opus-tools-0.1.2]$ ls -l *.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 287744 Jun 15 16:10 opusdec.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 327680 Jun 15 16:10 opusenc.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 34304 Jun 15 16:10 opusinfo.exe

Works like a charm, thanks for the tip

[NullC]

Opus has received the IETF's approval to become a standard. There will be some weeks of publication / pure-editorial delay and it will receive and RFC number and we'll make the big public announcements.

Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.