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

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.

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.

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)

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

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.

Playback length: 0m:00.348splease 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.

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.

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.