The reason why I'm asking about updates, is because there is very little discussions going on about using OPUS being used as archiving codec. I know the codec is designed to be an interactive codec, for VoIP and the likes, but the presentation that I've been watching, suggested that it is also very capable of creating transparent results at lower bitrates than Vorbis is even AAC. So, does OPUS make sense as archiving codec for music collections? I haven't found any documents discussing this.

I think the main developers are focused on getting it published by the IETF so it's all about getting the spec documentation polished up. But because they are at that stage I also believe this means the decoder is 99.9% done and isn't going to change.

The encoder on the other hand, is designed to be improvable even after the decoder is fixed, so I'd guess you might soon see further improvements around the time the spec gets publicised as "done", either because of renewed external interest or because the main developers have more time to work on that side of things.

But I'd guess, at least at first, they'll be aiming for the areas where Opus is fairly unique and has big advantages and building on that, rather than spending time taking on MP3 and AAC on their home turf. I'd guess any improvement in that domain will most likely be a by-product of other work.

All 30 tested original samples were concatenated into one file and resampled by SSRC resampler with highest quality settings (Ultra mode) 44.1 kHz -> 48 kHz. Then these files (48 kHz) were encoded by tested encoders. If You want to reproduce an individial bitrates You can get original files from here http://www.hydrogenaudio.org/forums/index....st&p=749742

Can we have some updates about OPUS? there isn't much info on the opus-code.org page. In fact, it seems pretty stagnant. Maybe on a technology readiness level or something?The last thing I've seen was the presentation about OPUS. I was looking through the IETF website (some links seem dead from the tread post), but even there seems to be close to no changes.[...]The reason why I'm asking about updates, is because there is very little discussions going on about using OPUS being used as archiving codec. I know the codec is designed to be an interactive codec, for VoIP and the likes, but the presentation that I've been watching, suggested that it is also very capable of creating transparent results at lower bitrates than Vorbis is even AAC. So, does OPUS make sense as archiving codec for music collections? I haven't found any documents discussing this.

You're correct that the main focus right now is on getting the standard published, so most commits are related to that.

There is an experimental branch with some pretty substantial (see posts above by IgorC) encoder perceptual enhancements— mostly serving the purpose of actually taking advantage of VBR... but other than fixing some regressions not a lot has happened with it lately. Right now the Xiph team is splitting resources between Opus and our new video codec work... and just shepherding the format through the IETF is itself a lot of work.

That said— file based usage is absolutely a priority for the time of the 1.0 release (which will happen along with publication of the standard). I've been spending time getting opus-tools, a set of simple command-line tools for encoding/decoding Opus in fixed files, ready for an initial official release— hopefully this coming weekend. I would _really_ appreciate testing and feedback, and if people need windows binaries made for testing, please let me know and I'd be glad to build some.

And the biggest news on this front is that we have support in Firefox, in the audio tag. It's only in the 'nightly' versions now and is preferences off and has a couple bugs, but it generally works great. This means that fairly rapidly after Opus' release the files will be playable on a significant fraction of desktop PCs— the browser is not exactly an ideal audio-player but compatibility is important..

For any Windows users who are waiting on binaries to play around with Opus, I've prepared a binary build of opus-tools.Feedback would be greatly appreciated. (I'm interested in if "opusdec.exe file.opus" plays audio on real windows systems, or if it only works in wine). I especially want to hear any bug reports or critical missing features.

As we approach the official release I'll get automated builds setup for opus and the exp4 tuning branches.

If anyone is interested in building a GUI oggdrop style tool for encoding Opus, perhaps just a GUI front end on opusenc, I think it would be very useful to people— if it's portable to *nix I'll help out (at least with review and testing), but I don't have the time free to drive the development myself.

1) Channel order (multichannel files)The channel order may be incorrect for multichannel files. Feeding the encoder WAVEFORMAT_PCM (no channelmask) and WAVEFORMAT_EXTENSIBLE (channelmask) makes no difference. I have no idea if this is an encoder or decoder issue, the .wav files were analyzed with Audacity/foobar2000.

'opusenc.exe' will crash when encoding from STDIN and the piped wav stream was created by ffmpeg. IIRC ffmpeg uses a value of 0 for the wav size header.Example: ffmpeg.exe -i "test.wav" -f wav -|opusenc.exe - "test_pipe_ffmpeg.opus"Solution: Most commandline encoder have an option to read to EOF and ignore the size header, this enables support for .wav files larger than 2/4 GB.

@dr. schankerThe Opus codec does not support multichannel audio, only mono and stereo ist supported.

The encoder accepted the linked multichannel .wav just fine. It even checked the channelmask in another testfile (WAVEFORMAT_EXTENSIBLE .wav) and changed channelorder (SL/SR remapped to RL/RR). I understand that mono/stereo has a higher priority and may be more polished codewise, but wanted to point out the multichannel issues anyway.

@dr. schankerThe Opus codec does not support multichannel audio, only mono and stereo ist supported.

Multichannel absolutely is supported.

I'll take care of the encoder issues that Dr. schanker found— I'd hoped to avoid issues with wav reading by using the oggenc input code, and stdin does work and has been extensively tested— in the two channel case. Edit: Can you get me your test.wav, as well as the output of the ffmpeg pipe redirected to a file? I'm unable to reproduce the issue piping from ffmpeg here. Works fine for me.

Opusdec's multichannel order absolutely is broken, known limitation at the moment. I was hoping someone to change the output in opusdec to use libao and so I didn't touch it— but that hasn't happened in time, as I really needed to get something in people's hands. Thank you so much for the feedback.

QUOTE (zerowalker @ May 28 2012, 09:27)

How can i get a compiled encoder of this codec:)?Would really like to try it out, as if it´s from the vorbis ppl, i am quite excited of it:)

If anyone is interested in building a GUI oggdrop style tool for encoding Opus, perhaps just a GUI front end on opusenc, I think it would be very useful to people— if it's portable to *nix I'll help out (at least with review and testing), but I don't have the time free to drive the development myself.

As Firefox can encode Opus (at least I assume it will soon for WebRTC uses), and decode WAV (and Ogg), and supports drag and drop of files, you might cover a fair bit of ground with a (relatively) simple Firefox extension (or even a webpage?). There's also the example of the Firefogg extension, but I think that includes ffmpeg for decoding various formats which makes it a bit more ambitious.

Integrating Javascript decoders for FLAC and ALAC would also score extra cool points.

The inputfile: "test_wav.7z" (5 MB) The piped data: "test_piped_bin.7z" (5 MB)I used the commandline: ffmpeg.exe -i "test.wav" -f wav - 1>"test_piped.bin"As suspected, the difference between both is that the piped file has the value 0 for RIFF and Data chunksize.

The inputfile: "test_wav.7z" (5 MB) The piped data: "test_piped_bin.7z" (5 MB)I used the commandline: ffmpeg.exe -i "test.wav" -f wav - 1>"test_piped.bin"As suspected, the difference between both is that the piped file has the value 0 for RIFF and Data chunksize.