IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 10 11 12 13 14 > »   
Closed TopicStart new topic
IETF Opus codec now ready for testing, That's CELT 0.11
jmvalin
post Aug 9 2012, 02:16
Post #276


Xiph.org Speex developer


Group: Developer
Posts: 485
Joined: 21-August 02
Member No.: 3134



QUOTE (Gainless @ Aug 8 2012, 16:04) *
Well, I've mainly tried Opus with electronic music and noticed things like unrelated sounds crushing in, artifacts on snares that made them sound like they were breaking apart (aren't that also pre-echos?) or simply heavy distortions on Hi-Hats and cymbals.


One thing worth checking is whether any of these artefacts are caused by clipping of the decoded values. Recent music is often mastered at such high level that lossy compression will cause some clipping when the output is a 16-bit int (not for float output). So it may be worth checking if a lower input level still causes these problems. If so, then it's something we're interested in fixing.
Go to the top of the page
+Quote Post
jmvalin
post Aug 9 2012, 02:30
Post #277


Xiph.org Speex developer


Group: Developer
Posts: 485
Joined: 21-August 02
Member No.: 3134



QUOTE (C.R.Helmrich @ Aug 8 2012, 17:56) *
That's simply because that l3enc version (which wasn't even version 1.0!) was buggy and frankly sounded like shit. I seriously doubt that at 64 kbps future Opus encoders will sound much better than the recent experimental branch. Which I haven't actually looked at or listened to, but from what NullC writes here it's already well tested for bugs and quality... which that l3enc version wasn't.


Obviously, the Opus reference implementation isn't crappy enough to have as much room for improvement as l3enc did. That being said, even from the current experimental branch there's still room for significant improvements. The current and experimental encoders still have a bunch of decisions that are made by rough heuristics that can definitely be improved. Feel free to give us a hand on those smile.gif
Go to the top of the page
+Quote Post
NullC
post Aug 9 2012, 03:23
Post #278





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (jmvalin @ Aug 8 2012, 18:30) *
Obviously, the Opus reference implementation isn't crappy enough to have as much room for improvement as l3enc did. That being said, even from the current experimental branch there's still room for significant improvements. The current and experimental encoders still have a bunch of decisions that are made by rough heuristics that can definitely be improved. Feel free to give us a hand on those smile.gif


There are also elements of the format that we don't make use of in the existing encoder— the ability to switch frame sizes, changing the bandpass on a frame by frame basis, or switching frames to straight mono automatically. Nor do we have any analysis that adds latency (at a minimum the pitch-prefilter, transient detection, and coding mode decision could be smarter with more lookahead).

There are also more exotic things that could be done which might have useful payoffs, e.g. non-uniform weighing the codebooks search, analysis on the post-prefilter signal, low rate RDO on the band energy.

This post has been edited by NullC: Aug 9 2012, 03:26
Go to the top of the page
+Quote Post
jmvalin
post Aug 9 2012, 05:54
Post #279


Xiph.org Speex developer


Group: Developer
Posts: 485
Joined: 21-August 02
Member No.: 3134



Oh, and we just released 1.0.0-rc and 1.0.1-rc. Please give those a try and report any problems so we can fix them for the final releases.
Go to the top of the page
+Quote Post
Gainless
post Aug 9 2012, 09:27
Post #280





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



Would be nice to have a compiled encoder.exe from this.

This post has been edited by Gainless: Aug 9 2012, 09:30
Go to the top of the page
+Quote Post
Garf
post Aug 9 2012, 10:06
Post #281


Server Admin


Group: Admin
Posts: 4886
Joined: 24-September 01
Member No.: 13



QUOTE (jmvalin @ Aug 9 2012, 06:54) *
Oh, and we just released 1.0.0-rc and 1.0.1-rc. Please give those a try and report any problems so we can fix them for the final releases.


QUOTE (Gainless @ Aug 9 2012, 10:27) *
Would be nice to have a compiled encoder.exe from this.


Something went wrong with that release candidate tar, I think, because it's missing all the stuff to compile with MSVC & Win32 that kode54 and me added.

The stuff in git is fine, that's compiled here: http://www.hydrogenaudio.org/forums/index....showtopic=96416
Go to the top of the page
+Quote Post
NullC
post Aug 9 2012, 18:47
Post #282





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Gainless @ Aug 9 2012, 01:27) *
Would be nice to have a compiled encoder.exe from this.


Nothing changed from the files on the site.
Go to the top of the page
+Quote Post
C.R.Helmrich
post Aug 10 2012, 00:44
Post #283





Group: Developer
Posts: 694
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



Jean-Marc, Greg, I see. The question is how much quality improvement you can get on top of the current encoder state by exploiting/encoder-tuning every tool the Opus decoder supports. From my experience in tuning Fraunhofer's HE-AAC encoder, the improvement can be quite large for individual items, but is surprisingly small on average over a large test set.

QUOTE (IgorC @ Aug 9 2012, 02:42) *
QUOTE (C.R.Helmrich @ Aug 8 2012, 18:56) *
What makes you come to that conclusion?

You know what it is. http://www.hydrogenaudio.org/forums/index....st&p=797609

OK, so you took the original_stereo_concat from that test and encoded it with Winamp's HE-AAC, VBR 2, to compare it against USAC?

QUOTE
If those USAC and HE-AAC encoders were tested in CBR mode how can You explain that your FhG HE-AAC (which I consider as best HE-AAC encoder) VBR ends up with practicaly identical quality? wink.gif

Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well. And besides, the tested SBR configuration isn't the only possible one (see the discussion on downsampled SBR elsewhere on HA). Anyway, it would be nice if you could post on HA (not in this thread) your test results which made you conclude, "VBR ends up with practicaly identical quality". Not only would this help me find out if my VBR code works suboptimally somewhere, it's also required by TOS#8.

QUOTE
Furthermore the advantage of USAC over HE-AAC is ... 8 kbps. Do You beleive that HE-AAC (64+8) 72 kbps is somehow superior to Opus 64 kbps?

Well, don't know. As you mentioned, which codec does better depends on the audio material. But I hear a significant improvement of HE-AAC 72 kbps over HE-AAC 64 kbps, so I'd say: possibly smile.gif Btw, where does that 8-kbps rule-of-thumb come from? Is that your own finding?

QUOTE
Consider my post as constructive criticism and not as personal attack.

I do and hope you do the same smile.gif

Chris

This post has been edited by C.R.Helmrich: Aug 10 2012, 00:54


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
IgorC
post Aug 10 2012, 03:07
Post #284





Group: Members
Posts: 1580
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (C.R.Helmrich @ Aug 9 2012, 20:44) *
OK, so you took the original_stereo_concat from that test and encoded it with Winamp's HE-AAC, VBR 2, to compare it against USAC?

Neither there was a need. It was HE-AAC (the version from a verification test) vs FhG/Winamp HE-AAC (and some other combinations).
I've received the complete package with USAC and HE-AAC samples at all tested bitrates, as well as some additional documentation of verification test.

QUOTE (C.R.Helmrich @ Aug 9 2012, 20:44) *
Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well.

It might be the case. Though there were more than 2 killer samples. Very difficult sample like Castanets, your super-killer Berlin Dug, a lot of trumpets, a lot of tonal samples, mixed samples speech+background noise/music, stereo samples like velvet. It doesn't fit into an easy-to-compress stuff.

QUOTE (C.R.Helmrich @ Aug 9 2012, 20:44) *
Anyway, it would be nice if you could post on HA (not in this thread) ...

It's my personal decision to make publicly available results or not. I have stopped to do that some time ago (with a few exceptions).


QUOTE
Well, don't know. As you mentioned, which codec does better depends on the audio material. But I hear a significant improvement of HE-AAC 72 kbps over HE-AAC 64 kbps, so I'd say: possibly smile.gif Btw, where does that 8-kbps rule-of-thumb come from? Is that your own finding?

http://www.hydrogenaudio.org/forums/index....st&p=781323
http://www.hydrogenaudio.org/forums/index....st&p=781338

QUOTE (C.R.Helmrich @ Jan 5 2012, 17:15) *
Correct. A more accurate rule of thumb for music and mixed content (not for pure speech) is: USAC at x kbps sounds as good as HE-AAC at x+8 kbps. (Edit: looking at the report Igor linked to, this seems to be roughly true for x >= 16.)
Go to the top of the page
+Quote Post
C.R.Helmrich
post Aug 11 2012, 09:24
Post #285





Group: Developer
Posts: 694
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (IgorC @ Aug 10 2012, 04:07) *
I've received the complete package with USAC and HE-AAC samples at all tested bitrates, as well as some additional documentation of verification test.
QUOTE (C.R.Helmrich @ Aug 9 2012, 20:44) *
Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well.

It might be the case. Though there were more than 2 killer samples. Very difficult sample like Castanets, your super-killer Berlin Dug, a lot of trumpets, a lot of tonal samples, mixed samples speech+background noise/music, stereo samples like velvet. It doesn't fit into an easy-to-compress stuff.

I just listened through the concatenated files, and you're right. It contains a lot of killer samples, basically every sample we used during the development of USAC. I had assumed it contains only the verification items. I guess I'll do my own MUSHRA test with these concatenated files then...


QUOTE
http://www.hydrogenaudio.org/forums/index....st&p=781323
http://www.hydrogenaudio.org/forums/index....st&p=781338
QUOTE (C.R.Helmrich @ Jan 5 2012, 17:15) *
Correct. A more accurate rule of thumb for music and mixed content (not for pure speech) is: USAC at x kbps sounds as good as HE-AAC at x+8 kbps. (Edit: looking at the report Igor linked to, this seems to be roughly true for x >= 16.)


biggrin.gif Thanks for reminding me of that post. I had already forgotten about that.

Chris


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
Gainless
post Aug 11 2012, 11:13
Post #286





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



Ok, here is one more sample that seems to make problems (with the 1.01 release candidate).

Bombat Sample

There is this sharp sound of some kind of distorted voice on which the encoder introduces noise/distortions. It's especially obvious at 64 kbps, but also noticeable at higher bitrates up to 160 kbps.
Go to the top of the page
+Quote Post
IgorC
post Aug 11 2012, 20:47
Post #287





Group: Members
Posts: 1580
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (Gainless @ Aug 7 2012, 09:41) *
Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg) or even just around 100 kbps (FhG AAC).

Bitrate is only part of story. It's always worthy to check if LAME, Aotuv or FhG decrease bitrate without any audible issues.

My results for this sample:
CODE

ABC/HR for Java, Version 0.53a, 11 August 2012
Testname:

Tester: IgorC

1L = D:\Samples\01_Kick_sample\FhG VBR 5 192 kbps.wav
2L = D:\Samples\01_Kick_sample\48kHz_192kbps_Opus(transients build)_44.1kHz_SoX.wav
3L = D:\Samples\01_Kick_sample\AoTuV VBR q6 192 kbps .wav
4R = D:\Samples\01_Kick_sample\LAME 3.99.5 V2.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Samples\01_Kick_sample\FhG VBR 5 192 kbps.wav
1L Rating: 4.9
1L Comment:
---------------------------------------
2L File: D:\Samples\01_Kick_sample\48kHz_192kbps_Opus(transients build)_44.1kHz_SoX.wav
2L Rating: 4.8
2L Comment:
---------------------------------------
3L File: D:\Samples\01_Kick_sample\AoTuV VBR q6 192 kbps .wav
3L Rating: 4.4
3L Comment: muddy bass. Probably as well as some tine pre-echo
---------------------------------------
4R File: D:\Samples\01_Kick_sample\LAME 3.99.5 V2.wav
4R Rating: 3.5
4R Comment: pre/post echo.
---------------------------------------

ABX Results:

Even such mature codecs like Vorbis and LAME drop bitrate but aslo drop quality. While only FhG AAC (VBR 5 192 kbps) could drop bitrate down to 120 kbps without any audible issues. I'm not sure how it will be easy or difficult to do that for Opus.



QUOTE (Gainless @ Aug 7 2012, 09:41) *
Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg) or even just around 100 kbps (FhG AAC).

Agree, CBR 96 kbps was already very good.
It's great sample where Opus could save bitrate. All encoders decrease the bitrate on this sample without any audible issue. FhG AAC (VBR 5 ~192 kbps) shines again, 105 kbps while keeping perfect quality.



QUOTE (Gainless @ Aug 11 2012, 07:13) *
Ok, here is one more sample that seems to make problems (with the 1.01 release candidate).

Bombat Sample

There is this sharp sound of some kind of distorted voice on which the encoder introduces noise/distortions. It's especially obvious at 64 kbps, but also noticeable at higher bitrates up to 160 kbps.

It's rather a killer sample itself than a particular issue for 1.0.1. I couldn't find any other lossy codec that makes any better for this sample.
Comparison with HE-AAC:
CODE

ABC/HR for Java, Version 0.53a, 11 August 2012
Testname:

Tester: IgorC

1L = D:\Samples\HA_opus_topic\03 Bombat\Opus_EXP7_Transients_64kbps_resampled_44.1kHz_SoX.wav
2L = D:\Samples\HA_opus_topic\03 Bombat\Opus_1.0.1_64kpbs_resampled_44.1kHz_SoX.wav
3R = D:\Samples\HA_opus_topic\03 Bombat\FHG_VBR3_64kbps.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Samples\HA_opus_topic\03 Bombat\Opus_EXP7_Transients_64kbps_resampled_44.1kHz_SoX.wav
1L Rating: 3.8
1L Comment:
---------------------------------------
2L File: D:\Samples\HA_opus_topic\03 Bombat\Opus_1.0.1_64kpbs_resampled_44.1kHz_SoX.wav
2L Rating: 3.8
2L Comment:
---------------------------------------
3R File: D:\Samples\HA_opus_topic\03 Bombat\FHG_VBR3_64kbps.wav
3R Rating: 3.4
3R Comment:
---------------------------------------

ABX Results:


This post has been edited by IgorC: Aug 11 2012, 20:49
Go to the top of the page
+Quote Post
IgorC
post Aug 11 2012, 21:52
Post #288





Group: Members
Posts: 1580
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



The first quote of previous post is wrong.
Shoud be
QUOTE (Gainless @ Aug 7 2012, 08:03) *
I know that the argumentation "If Vorbis can do it then Opus can do it even better" is not really appropiate in general, I'm mainly talking about the really basic examples where a lot of encoders are behaving similarly.

Here is the kick sample I mentioned.
Kick sample

Tested with a target bitrate of 192 kbps and the difference to other encoders is pretty obvious: While Lame, FhG AAC and Vorbis are using 120-130 kbps in average, Opus is reaching out with 181 kbps.

Go to the top of the page
+Quote Post
Kvanto
post Aug 11 2012, 21:57
Post #289





Group: Members
Posts: 15
Joined: 6-April 09
Member No.: 68697



Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?

This post has been edited by Kvanto: Aug 11 2012, 21:57
Go to the top of the page
+Quote Post
saratoga
post Aug 11 2012, 22:35
Post #290





Group: Members
Posts: 5147
Joined: 2-September 02
Member No.: 3264



QUOTE (Kvanto @ Aug 11 2012, 16:57) *
Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?


Pretty much anything will be transparent. At those bitrates, you can probably use mp2 just as well.
Go to the top of the page
+Quote Post
eahm
post Aug 11 2012, 23:05
Post #291





Group: Members
Posts: 1168
Joined: 11-February 12
Member No.: 97076



foobar2000 1.1.14 beta 3 released (http://www.foobar2000.org/download):

Added Opus encoding support in Converter (requires external opusenc.exe binary) (beta 3).

This post has been edited by eahm: Aug 11 2012, 23:06
Go to the top of the page
+Quote Post
jensend
post Aug 11 2012, 23:32
Post #292





Group: Members
Posts: 149
Joined: 21-May 05
Member No.: 22191



QUOTE (Kvanto @ Aug 11 2012, 14:57) *
Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?
Both of these codecs should be basically transparent by the time you reach 192kbps (if not long before). Being able to find a sample where you can hear any difference -in completely ideal circumstances- between either codec at 192kbps and the original would be extraordinarily rare. For the quality of either at 192kbps to be worse than the original by enough to seriously impact your normal music-listening experience is unheard of.

How on earth would you propose to compare codec performance at bitrates well above their normal transparency threshholds? What basis would you have for saying "though x and y both sound identical to the original, x performs better than y"?

If you're trying to preserve non-perceptible details of the original then it's foolish to be looking at lossy codecs, which are designed around human perception. (Lossless codecs often get roughly 50% compression; for CD audio that means ~700kbps.)

If you only care about how it's perceived when listening then there's no point in considering >192kbps rates with either of these codecs.
Go to the top of the page
+Quote Post
Gainless
post Aug 12 2012, 10:24
Post #293





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



Thanks for the tests Igor, noticed the bad performance of Lame at the Kick sample and FhG at the Bombat sample now either. A definately Opus related problem I've noticed though is that the exp version performs generally better at tonal samples than the "official" one, but in return often worse at certain other situations. A good example is this sample:

VD Sample

While the 1.0.1 rc handles the rythmic snare in it pretty well (at 64 kbps) the exp version introduces some kind of crackling sounds.

This post has been edited by Gainless: Aug 12 2012, 10:25
Go to the top of the page
+Quote Post
larryfine
post Aug 12 2012, 17:40
Post #294





Group: Members
Posts: 60
Joined: 21-September 10
Member No.: 84040



I'm a strange here so...

Original file:

01. Giorgio Federico Ghedini - Mazurka (1908).wav --> 44.056.576 bytes

Compressed with Opus:

> opusenc.exe --bitrate 512 --music

01. Giorgio Federico Ghedini - Mazurka (1908).opus --> 15.794.176 bytes (lossy)

Compressed with TAK:

> Takc.exe -e -ihs -pMax

01. Giorgio Federico Ghedini - Mazurka (1908).tak --> 12.816.384 bytes (lossless)



--------------------
loquor mee menti: factus de materia, cinis elementi...
Go to the top of the page
+Quote Post
Gainless
post Aug 12 2012, 17:48
Post #295





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



Well, if you set the encoder to 512 kbps it'll keep the resulting file around that bitrate, no matter how far it could be compressed further losslessly.
Go to the top of the page
+Quote Post
zerowalker
post Aug 12 2012, 18:48
Post #296





Group: Members
Posts: 268
Joined: 6-August 11
Member No.: 92828



QUOTE (NullC @ Jul 3 2012, 15:21) *
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.



I say Mumble, but it already says itīs going to have support so not sure it counts?
Other than that, i say Megui, for encoding?

And Youtube for allowing Opus decoding for there Re-Encode (probably a bit harder here as itī+s not open source or anything)
Go to the top of the page
+Quote Post
CoRoNe
post Aug 12 2012, 21:04
Post #297





Group: Members
Posts: 187
Joined: 31-May 05
From: Netherlands
Member No.: 22417



Doesn't MeGUI use Avisynth and BassAudio for audio encoding? In that case it's already possible.


--------------------
DC-Bass Source Mod: http://reino.degeelebosch.nl
Go to the top of the page
+Quote Post
zerowalker
post Aug 12 2012, 21:40
Post #298





Group: Members
Posts: 268
Joined: 6-August 11
Member No.: 92828



QUOTE (CoRoNe @ Aug 12 2012, 22:04) *
Doesn't MeGUI use Avisynth and BassAudio for audio encoding? In that case it's already possible.


Not sure what BassAudio is?

But well, itīs probably Very Easy to implement, as it just redirect to the encoder pretty much.


But, does anyone know if youtube supports Opus? (canīt see that it does).
Go to the top of the page
+Quote Post
CoRoNe
post Aug 12 2012, 22:30
Post #299





Group: Members
Posts: 187
Joined: 31-May 05
From: Netherlands
Member No.: 22417



I'm sorry, I'm mixing up encoding and decoding.
Opus decoding through Avisynth is already possible with BassAudio, but the encoding part...that's indeed up to MeGUI to add a profile. In the meantime you could use avs2pipe to pipe Avisynth's audio output to the input of the audio encoder of your choosing.


--------------------
DC-Bass Source Mod: http://reino.degeelebosch.nl
Go to the top of the page
+Quote Post
zerowalker
post Aug 12 2012, 23:02
Post #300





Group: Members
Posts: 268
Joined: 6-August 11
Member No.: 92828



QUOTE (CoRoNe @ Aug 12 2012, 23:30) *
I'm sorry, I'm mixing up encoding and decoding.
Opus decoding through Avisynth is already possible with BassAudio, but the encoding part...that's indeed up to MeGUI to add a profile. In the meantime you could use avs2pipe to pipe Avisynth's audio output to the input of the audio encoder of your choosing.


Oh, well i will just wait for MeGUI, as youtube doesnīt support Opus yet i think:)
Go to the top of the page
+Quote Post

23 Pages V  « < 10 11 12 13 14 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th December 2014 - 17:10