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

[lvqcl]

Something strange with experimental codec: I took 41_30 sample and encoded it with "--bitrate 96 --music". The bitrate is 109 kbps. Then I replaced the right channel with silence. Bitrate -> 105 kbps. Replaced the left channel (of the original sample) with silence -> 32 kbps. So:

Both channels in a stereo file -> 109 kbps;
Left channel only -> 105 kbps;
Right channel only -> 32 kbps.


1.0.1 rc works fine, BTW.

This post has been edited by lvqcl: Aug 13 2012, 15:23

[jmvalin]

Something strange with experimental codec: I took 41_30 sample and encoded it with "--bitrate 96 --music". The bitrate is 109 kbps. Then I replaced the right channel with silence. Bitrate -> 105 kbps. Replaced the left channel (of the original sample) with silence -> 32 kbps. So:

Both channels in a stereo file -> 109 kbps;
Left channel only -> 105 kbps;
Right channel only -> 32 kbps.

Thanks very much for reporting this. It was a silly bug that is now fixed in git. Let us know if you find any other issues where the experimental encoder is worse than 1.0.1-rc. Or even when it generally does poorly on a certain file.

[NullC]

Thanks very much for reporting this. It was a silly bug that is now fixed in git. Let us know if you find any other issues where the experimental encoder is worse than 1.0.1-rc. Or even when it generally does poorly on a certain file.

And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip As JM says, thanks!

[LigH]

Again with Stranglehold:

LAME 3.99.5 -V2: 180.0 kbps
Ogg Vorbis aoTuVb6.03 SSE3 -q5: 129.1 kbps
QAAC 1.39 (CATB 7.9.7.9) -V82: 147.7 kbps
Opus 0.9.11-92 (rel. gc329045) music 160: 157.8 kbps (149.6-278.0)
Opus 0.9.11-139 (exp. g2c7f8cd) music 160: 187.8 kbps (138.8-287.2)
Opus 0.9.11-142 (exp. 32024cb5) music 160: 189.2 kbps (137.6-311.6)

Opus 0.9.11-146 (exp. gdc4f83b) music 160: 190.6 kbps (137.2-316.0)

[punkrockdude]

And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip As JM says, thanks!

The link is dead. Regards.

[Garf]

And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip As JM says, thanks!

The link is dead. Regards.

WORKSFORME.

[LigH]

Worked earlier today; now it returns emptiness. – Worked again. But who knows, sometimes I have issues with HTTPS and some proxy.

This post has been edited by LigH: Aug 14 2012, 09:58

[punkrockdude]

And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip As JM says, thanks!

The link is dead. Regards.

WORKSFORME.

It works for me now, too.

[Gecko]

And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip As JM says, thanks!

Note: these are my first steps with Opus, so I may have done something wrong.

Using the above build with foobar 1.1.14 beta 3 I tried the first track I came across, which happened to be "Pendulum - Slam" from the album "Hold Your Colour" which can be classified as Drum 'N' Bass. The quality was unexpectedly bad: mushy/metallic highs. Quick ABX 15/16. Done on my not-so-amazing PC speakers with a washing machine running in the background.

For kicks I tried using NeroACC in 2-pass ABR mode to achieve the same bitrate (which was 54kbps). The result sounded fine to me under the same circumstances. I may have imagined some lowpassing but it wasn't readily audible so I didn't bother to ABX.

The point is that Opus did significantly worse than NeroACC when I was expecting it to be similar. I can provide a sample if needed.

Settings in foobar for Opus: Target Bitrate 64, Bitrate Management VBR, Optimize for Music.

CODE

foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/14 15:07:19

File A: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro).flac
File B: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro)_opus.opus

15:07:19 : Test started.
15:07:44 : 01/01 50.0%
15:07:59 : 01/02 75.0%
15:08:16 : 02/03 50.0%
15:08:54 : 03/04 31.3%
15:09:00 : 04/05 18.8%
15:09:05 : 05/06 10.9%
15:09:10 : 06/07 6.3%
15:09:25 : 07/08 3.5%
15:09:33 : 08/09 2.0%
15:09:42 : 09/10 1.1%
15:09:53 : 10/11 0.6%
15:10:03 : 11/12 0.3%
15:10:10 : 12/13 0.2%
15:10:13 : 13/14 0.1%
15:10:17 : 14/15 0.0%
15:10:27 : 15/16 0.0%
15:10:31 : Test finished.

----------
Total: 15/16 (0.0%)

[NullC]

The point is that Opus did significantly worse than NeroACC when I was expecting it to be similar. I can provide a sample if needed.

Samples are helpful, also— can you try the non-experimental encoder (see http://www.opus-codec.org/downloads/ ) and see if its obviously better?

[Gecko]

Samples are helpful, also— can you try the non-experimental encoder (see http://www.opus-codec.org/downloads/ ) and see if its obviously better?

Sample: http://www.hydrogenaudio.org/forums/index....showtopic=96497

Using Headphones (Beyerdynamic DT 880):
Original vs. non-experimental (libopus 0.9.11-134-gda3b5f7): ABX 16/16 (felt significantly harder than this noon on my PC speakers)
experimental vs. non-experimental: ABX failed

Using PC speakers again (Teufel Concept E Magnum):
experimental vs. non-experimental: ABX 16/16 relatively easy. Non-experimental is clearly better.

Bitrates for the complete track (target bitrate 64 kbps):
NonExp: 62 kbps
Exp: 54 kbps

I would have expected the artifact to be blatantly obvious on headphones, but the opposite was the case. This was a first for me.

Orig vs. NonExp on headphones

CODE

foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/14 20:01:15

File A: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro).flac
File B: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro)_NonExp.opus

20:01:15 : Test started.
20:01:50 : 01/01 50.0%
20:01:55 : 02/02 25.0%
20:02:02 : 03/03 12.5%
20:02:54 : 04/04 6.3%
20:03:14 : 05/05 3.1%
20:03:25 : 06/06 1.6%
20:04:01 : 07/07 0.8%
20:04:23 : 08/08 0.4%
20:04:44 : 09/09 0.2%
20:04:59 : 10/10 0.1%
20:05:21 : 11/11 0.0%
20:05:33 : 12/12 0.0%
20:06:15 : 13/13 0.0%
20:06:34 : 14/14 0.0%
20:08:13 : 15/15 0.0%
20:08:20 : 16/16 0.0%
20:08:22 : Test finished.

----------
Total: 16/16 (0.0%)

Exp vs. NonExp on PC speakers

CODE

foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/14 20:46:39

File A: E:\tmp\Pendulum - Slam (excerpt)_Exp.opus
File B: E:\tmp\Pendulum - Slam (excerpt)_NonExp.opus

20:46:39 : Test started.
20:47:21 : 01/01 50.0%
20:47:34 : 02/02 25.0%
20:47:45 : 03/03 12.5%
20:48:04 : 04/04 6.3%
20:48:14 : 05/05 3.1%
20:48:36 : 06/06 1.6%
20:49:22 : 07/07 0.8%
20:49:41 : 08/08 0.4%
20:49:58 : 09/09 0.2%
20:50:05 : 10/10 0.1%
20:50:12 : 11/11 0.0%
20:50:30 : 12/12 0.0%
20:50:43 : 13/13 0.0%
20:51:02 : 14/14 0.0%
20:51:38 : 15/15 0.0%
20:51:45 : 16/16 0.0%
20:51:48 : Test finished.

----------
Total: 16/16 (0.0%)

[El Stew]

Thanks very much for reporting this. It was a silly bug that is now fixed in git. Let us know if you find any other issues where the experimental encoder is worse than 1.0.1-rc. Or even when it generally does poorly on a certain file.

Don't know if it matters, but:

In the VisualStudio project files for the experimental encoder there are some missing .c files that prevent it from compiling successfully. They have to be added manually.

Also some of the code in the experimental encoder uses the keyword "inline", which VisualStudio doesn't like in plain C code. Had to replace it with "__inline".

This post has been edited by El Stew: Aug 14 2012, 22:10

[LigH]

Again with Stranglehold:

LAME 3.99.5 -V2: 180.0 kbps
Ogg Vorbis aoTuVb6.03 SSE3 -q5: 129.1 kbps
QAAC 1.39 (CATB 7.9.7.9) -V82: 147.7 kbps
Opus 0.9.11-92 (rel. gc329045) music 160: 157.8 kbps (149.6-278.0)

Opus 0.9.11-134 (rel. gda3b5f7) music 160: 157.8 kbps (149.6-278.0) -- no change between Opus Tools 0.1.3 and 0.1.4

Opus 0.9.11-139 (exp. g2c7f8cd) music 160: 187.8 kbps (138.8-287.2)
Opus 0.9.11-142 (exp. 32024cb5) music 160: 189.2 kbps (137.6-311.6)
Opus 0.9.11-146 (exp. gdc4f83b) music 160: 190.6 kbps (137.2-316.0)

__

@ zerowalker:

Apropos ... unnecessary full-quotes are redundancy as well.

This post has been edited by LigH: Aug 15 2012, 08:35

[lvqcl]

This sample is easy to ABX with --bitrate 128 --music; both exp and 1.0.1-rc encoders.
(time range: 0:07.1 - 0:09.6)

CODE

foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/15 15:47:24

File A: E:\Samples\Interesting.flac
File B: E:\Samples\Interesting.opus

15:47:24 : Test started.
15:47:52 : 01/01 50.0%
15:47:56 : 02/02 25.0%
15:48:01 : 03/03 12.5%
15:48:07 : 04/04 6.3%
15:48:14 : 05/05 3.1%
15:48:18 : 06/06 1.6%
15:48:25 : 07/07 0.8%
15:48:30 : 08/08 0.4%
15:48:35 : 09/09 0.2%
15:48:39 : 10/10 0.1%
15:48:43 : 11/11 0.0%
15:48:47 : 12/12 0.0%
15:48:52 : Test finished.

----------
Total: 12/12 (0.0%)

[mamboman]

How can I preserve metadata/tags when converting flac files to opus on Linux?

When using oggenc to convert from flac to vorbis the tags are automatically preserved

With opusenc, however, as far as I can tell, I need to decode flac to wav first and then convert wav to opus and, in the process, tagging information is lost.
If I try to convert flac files directly to opus using opusenc I get an error message "error parsing input file".

Is there or will there be an easy way to preserve flac tags with opusenc - perhaps a command line switch?
I did try writing a bash script to do this but was struggling.

Is it necessary to convert to wav first or can opusenc convert flac to opus after all but I am doing something wrong?

I am using Debian Wheezy.

By the way, I think opus is a terrific codec and hope it gains wide adoption - it certainly deserves to.

[The Link]

How can I preserve metadata/tags when converting flac files to opus on Linux?

You could try it with caudec.

[jmvalin]

To those who had problems on Windows, please try the new 1.0.1-rc2 release and see if it works now.

[NullC]

To those who had problems on Windows, please try the new 1.0.1-rc2 release and see if it works now.

Compiling on Windows.

[NullC]

Jmvalin has been working on some doubly experimental stuff that we hope improves the transient response.
It would be helpful if people could test it and compare it against the prior EXP builds: https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip (and against master, if you like but the comparison with regular exp is most important).

[LigH]

Yikes! Lots of debugging output!

Bitrate is in a similar high and very variable range as the other experimental builds.

Can't offer you a listening test right now, sorry.

[IgorC]

Can't offer you a listening test right now, sorry.

What do You mean?

[LigH]

I am at work in the office. Would be strange if I pumped up the volume right now.

[NullC]

Bitrate is in a similar high and very variable range as the other experimental builds.

This is not a problem. (I'm only commenting because people keep seeing these posts and thinking something is wrong and then not testing.)

[LigH]

Uhm ... wow. You make it really hard for me. Either my ears are too old now, or your algorithms are too good.

At 64 kbps, I could hardly spot any really obvious artefacts anymore. So I turned down the target bitrate to 48 kbps. And still, the artefacts were not even really annoying.

True, the release encoder has its flaws you can point at. In "Peter Heppner - Twelve"*, it is especially the second theme with the "subthreshold finger cymbals (or triangle)" (0:55-1:07 – for the complete song, not only Roberto's test part); they start to disappear in crackling noise.

But the experimental encoders are able to squeeze still a bit of melodic sound out of this part. And both are so similar to me, I couldn't decide which one is better.

Maybe another sample would tell me better. Maybe another listener has a more certain opinion than me.
_

*MODERATION: attempt to circumvent TOS#9 removed.

This post has been edited by greynol: Aug 16 2012, 17:57

[punkrockdude]

I've tested the latest exp version and I am so surprised of the quality. Ten years years ago companies said that wma and aac sounded like mp3 128kbps at half the bitrate. That was not true, but now, Opus is almost there in my opinion.

By the way why is the sample rate always 48khz and does this make it possible for aliasing IF the decoder somehow resamples it back to 44.1khz? Another question is if 96kHz is or will be supported?

Regards.