Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: IETF Opus codec now ready for testing (Read 392290 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #300
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.

IETF Opus codec now ready for testing

Reply #301
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.

IETF Opus codec now ready for testing

Reply #302
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!

IETF Opus codec now ready for testing

Reply #303
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)



IETF Opus codec now ready for testing

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


IETF Opus codec now ready for testing

Reply #308
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: [Select]
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%)


IETF Opus codec now ready for testing

Reply #310
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: [Select]
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: [Select]
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%)

IETF Opus codec now ready for testing

Reply #311
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".

IETF Opus codec now ready for testing

Reply #312
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.

IETF Opus codec now ready for testing

Reply #313
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: [Select]
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%)


IETF Opus codec now ready for testing

Reply #314
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.


IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

Reply #317
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.

IETF Opus codec now ready for testing

Reply #318
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).

IETF Opus codec now ready for testing

Reply #319
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.


IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

Reply #322
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.)

IETF Opus codec now ready for testing

Reply #323
 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.

IETF Opus codec now ready for testing

Reply #324
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.