Skip to main content
Topic: Opus 1.3-rc2 (Read 6886 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus 1.3-rc2

Reply #25
Isn't the point of software to be as efficient as possible?

No, the point of software is to serve the needs of its user(s).

Well, the needs of the users can vary drastically. For example:
- On a mobile phone, a user needs the software to not drain the battery more than absolutely necessary.
- On a supercomputer, a user needs the software to run as correctly and quickly as possible
- At a CD pressing plant owned by Sony or BMG at a certain time in the past, a user needs the software to install itself onto another user's PC as a rootkit.
- On a PC, the user needs other users to not install nefarious software, such as a rootkit, onto their machine AND to play the CD they just bought. The user may or may not prefer a faster encode over smaller files, as well. Personally, I prefer the smaller file.

;)

On-topic: I'm glad to see a new release of the Opus tools! When I first tried converting some of my FLAC files with the 1.2 version opus-tools, I was happily surprised at the size/quality ratio improvement over OGG Vorbis. I also found it far easier than either monkeying around with ripping an audiobook to wav->encoding with speexenc->tagging or using ffmpeg->tagging.

Now, if Rockbox's support for it didn't tend to stutter or crash on my Sansa players, I could switch to using it full-time for everything. :( That's not on anyone here, of course. :)

Couldn't agree more with you.

I do have an AMD Ryzen CPU so setting it up to use level 10 is nothing. Also, if the quality goes up to 10 it is for a reason. If it is disabled, that doesn't mean I can't use it. In fact, I wanted to use level 10 to make the maximum use of the code and the CPU.

Having said that, I, as a developer am setting up a distributed computing server to handle all my encoding demands, which I tested today and worked. I can speed up encoding by a lot this way.

-----

Back on topic,

The Hiby players are capable of decoding Opus really great:-)

Re: Opus 1.3-rc2

Reply #26
You can also use external resampler like SoX (with "Very High Quality" setting). It's still way faster and mathematically more accurate than built-in Speex resampler (q 10)
src.infinitewave.ca

 Though being mathematically more accurate doesn't mean audibly superior.


Re: Opus 1.3-rc2

Reply #27
You can also use external resampler like SoX (with "Very High Quality" setting). It's still way faster and mathematically more accurate than built-in Speex resampler (q 10)
src.infinitewave.ca

 Though being mathematically more accurate doesn't mean audibly superior.



Yep that works pretty well (for the paranoid like me).

For the curious, here's the one-liner script I have on my linux server that does this for me:
sox-opus.sh:
Code: [Select]
#!/bin/sh
find "$@" -type f -iname '*.flac' -print0 | nice -n 15 xargs -0 -P 4 -I {} sh -c 'sox "{}" -r 48k -b 24 -C 0 -t flac - | opusenc --vbr --bitrate 144 - /mnt/target/folder/"`basename "{}"`"-$(date +%s).opus'
Since sox & opus run mostly in parallel and because of the parallel execution of multiple files through xargs it's not even that slow.

Re: Opus 1.3-rc2

Reply #28
Since sox command handles everything in integer, clipping can always occur when used without care.
If you are after sox for tiny bit of improvement in mathematical accuracy that likely mean nothing after lossy encoding, why don't you care about clipping?
foobar2000 + sox resampler plugin doesn't have this issue.

Re: Opus 1.3-rc2

Reply #29
Since sox command handles everything in integer, clipping can always occur when used without care.
If you are after sox for tiny bit of improvement in mathematical accuracy that likely mean nothing after lossy encoding, why don't you care about clipping?
foobar2000 + sox resampler plugin doesn't have this issue.

I do care about clipping and am aware of this problem. How does the foobar plugin prevent it? Just by doing everything in floating point? Sadly using foobar2000 isn't really an option on my headless linux server. Also I'm not sure that pushing individual samples to 0db results in any audible degradation, as opposed to real life clipping where the actual waveform is damaged, as multiple samples are clipped.

I'm no sox expert and I just started to use it for 'peace of mind'. Is there anything I can do to make my processing chain better?

Re: Opus 1.3-rc2

Reply #30
On linux, you could use ffmpeg (need to be built with soxr resampler enabled) instead of sox:
ffmpeg -i INPUT -af aresample=48000:resampler=soxr -c:a pcm_f32le -f wav OUTPUT
Not easy to type/remember, should not matter for scripting.


Re: Opus 1.3-rc2

Reply #31
I do care about clipping and am aware of this problem. How does the foobar plugin prevent it? Just by doing everything in floating point? Sadly using foobar2000 isn't really an option on my headless linux server. Also I'm not sure that pushing individual samples to 0db results in any audible degradation, as opposed to real life clipping where the actual waveform is damaged, as multiple samples are clipped.

I'm no sox expert and I just started to use it for 'peace of mind'. Is there anything I can do to make my processing chain better?

Actually, if you just let opusenc do the job everything will be just fine because its processing chain is all float and there will be no intermediate clipping. Seriously, the quality degradation from the resampling is far far less than even what you get from 510 kb/s Opus. So if you're concerned with resampling, why are you using a lossy codec in the first place?

Re: Opus 1.3-rc2

Reply #32
@jmvalin any chance you or any opus-tools developers could review this Pull Request?

https://github.com/xiph/opus-tools/pull/38

It basically allows encoding without specifying an output filename. Using the input filename and changing the extension to .opus if no output name is provided :-)

Re: Opus 1.3-rc2

Reply #33
Actually, if you just let opusenc do the job everything will be just fine because its processing chain is all float and there will be no intermediate clipping. Seriously, the quality degradation from the resampling is far far less than even what you get from 510 kb/s Opus. So if you're concerned with resampling, why are you using a lossy codec in the first place?

Okay to reiterate: I'm just using the sox->opus chain because of the supposed mathematical superiority of sox's resampling algorithm. I'm not making any claims about audible quality, I'm just totally fine with wasting a few CPU cycles to get a slightly improved result, that's inaudible in all likely scenarios.

Now in regards to clipping. This is interesting and I've wondered about the introduction of clipping before. As an example I'll attach a screenshot from a track that I've recently converted, where I noticed sox warning me about clipping.

On the top is the original flac. In the middle is the result after processing with sox->opus and the last one is just using opusenc.

Finally I also tested foobar2000 with the sox plugin -> opus chain. Looks pretty much the same, but maybe I'm misunderstanding what nu774 was referring to. I assume ffmpeg is going to be similar.

As far as I understand it, this kind of clipping is pretty much unavoidable when converting to a sampling rate that doesn't have a divisor from the original sampling rate. At first glance it seems sox is doing a little bit better here, but I couldn't find a function to count the amount of clipped samples in audacity on the fly.

Re: Opus 1.3-rc2

Reply #34
Any overs introduced by either Opusenc or SoX plugin are recoverable by reducing the gain in floating-point mode (such as ReplayGain in Foobar or some other software). You can test it by encoding a 32-bit file that has significant audible positive peaks. Clipping added by sox command line utility is hard and permanent. It appears that the test files have been converted to 16-bit fixed-point during loading in Audacity and have been permanently clipped too, which is a flaw in this program or process used to perform this test.

I wouldn't worry too much about clipping from a resampler if the end format is lossy at lowish bitrate. The codec, especially Opus, will change the waveform much more. Clipping could potentially occur during downmixing multichannel or in synthesised music from video games. It is easy to eliminate this issue by using 32-bit accuracy during processing.

Re: Opus 1.3-rc2

Reply #35
Or you could, like, continue using the built-in resampler and not really notice a difference.

Another bonus of the built-in resampler: It has the same license as the rest of the library, whereas the SoX resampler is... GPL of some version, I believe?

Re: Opus 1.3-rc2

Reply #36
Okay to reiterate: I'm just using the sox->opus chain because of the supposed mathematical superiority of sox's resampling algorithm. I'm not making any claims about audible quality, I'm just totally fine with wasting a few CPU cycles to get a slightly improved result, that's inaudible in all likely scenarios.

Except that in all likelihood, you're spending extra CPU cycles to make the final result slightly *worse*, for multiple reasons:
  • If your intermediate data is 16-bit PCM (and opusenc doesn't currently take anything else), then you have the clipping issue, and if you scaledown like was suggested then you have more quantization noise
  • If your intermediate data is 16-bit PCM, then just the fact that you're rounding between the resampling and the encoding adds noise
  • The difference between different different resampler qualities is how much of the bandwidth gets retained below Nyquist. Except that when converting from 44.1 kHz to 48 kHz, the Nyquist rate is 22.05 kHz and Opus will actually throw away anything above 20 kHz, so as long as your resampler doesn't cut anything below 20 kHz, you've good.
  • Because Opus uses the MDCT to cut what's above 20 kHz, there's going to be a tiny bit of aliasing left and any frequency above 20 kHz that gets removed by the resampler will actually *improve* quality because it won't go through the MDCT
  • All resamplers cause small amounts of (mostly inaudible) echo and pre-echo due to the filter size (ringing), so the higher the resampler quality, the larger the filter and the more ringing you get. Again, I've never been able to hear that, but it's another example of longer filters being theoretically worse.

So overall, there's exactly zero reasons why using SoX will sound better, but several reasons for which it could sound very slightly worse (I doubt you'd be able to ABX). So if you actually want to be on the safe side, just let the encoder handle the resampling.

As a general comment, if some simple processing actually gave you better quality, trust us that it would already be in Opus and enabled by default (or easily accessible through an option if it increased the CPU by a lot). I like to believe that we're not complete idiots... and if you don't believe that claim then why are you using Opus in the first place :-)

Re: Opus 1.3-rc2

Reply #37
  • If your intermediate data is 16-bit PCM (and opusenc doesn't currently take anything else),

I'm using 24 bit FLAC as intermediate format. Seems to work fine for opusenc.

Re: Opus 1.3-rc2

Reply #38
  • If your intermediate data is 16-bit PCM (and opusenc doesn't currently take anything else),
I'm using 24 bit FLAC as intermediate format. Seems to work fine for opusenc.
I'm pretty sure that opusenc can eat up to 32bit float just fine.
I guess this "currently" just refers to the script in your post, but maybe I'm wrong.

Anyway, I don't understand why you choose FLAC as an intermediate format (instead of uncompressed format) , and re-quantization/clipping occurs even when you pick 24bit.

Re: Opus 1.3-rc2

Reply #39
Quote
Anyway, I don't understand why you choose FLAC as an intermediate format (instead of uncompressed format) ,

It preserves tags and is not as easy to fuck up the audio as with handling raw PCM streams. It just works *shrug*

Quote
and re-quantization/clipping occurs even when you pick 24bit.

Sure. Did you look at the screenshots? I'm biased, but it _looks_ like my method introduced less clipping than just using opusenc or your proposal of foobar2000 sox&opus. This is not a hill I wish to die on, but it's you who brought up the supposed problem of clipping: Can you point to what I'm doing (or how I'm thinking) wrong if you still believe foobar2000 to be superior here? I'm attaching screenshots of the fb2k setup.

Re: Opus 1.3-rc2

Reply #40
(acoustic) "Love Interruption" Jack White Acoustic Recordings 1998-2016 which is 24/96 flac and only 2:37 long.
I converted it to 160kbps. It came out to 14.4 MB.

Re: Opus 1.3-rc2

Reply #41
I'm using 24 bit FLAC as intermediate format. Seems to work fine for opusenc.
OK, then strike point #2. The four other points still stand. Mostly the few extra Hz of bandwidth you're preserving with the better resampler are the first things Opus will throw away.

Re: Opus 1.3-rc2

Reply #42
Sure. Did you look at the screenshots? I'm biased, but it _looks_ like my method introduced less clipping than just using opusenc or your proposal of foobar2000 sox&opus.
Your test is flawed. Your initial SoX conversion clips the signal and reduces peaks so the Opus will have less peaks too. Here's real demonstration how your method clips and floating point pipeline doesn't. Screenshots from Opus converted to 32-bit WAV, as Audition doesn't support Opus directly.
command line SoX -> FLAC -> Opus:


foobar2000 SoX -> Opus:


Re: Opus 1.3-rc2

Reply #43
jmvalin: quick question unrelated to this silly debate. Will there be new windows builds for opus-tools that incorporate the fix in libopusenc about gapless buffering? Or is it not somethign that I'd have to worry about when using the 1.3-rc2 builds available here?


 

Re: Opus 1.3-rc2

Reply #46
To discussion about resampler.
Even if quality doesn't matter, SoX is able to provide the same quality as Speex while being much faster. Isn't it?

Re: Opus 1.3-rc2

Reply #47
Thank you.  :)

Re: Opus 1.3-rc2

Reply #48
(acoustic) "Love Interruption" Jack White Acoustic Recordings 1998-2016 which is 24/96 flac and only 2:37 long.
I converted it to 160kbps. It came out to 14.4 MB.
The size of the source material (24/96) determines the finial size opus?

Re: Opus 1.3-rc2

Reply #49
Quote from: soundping
The size of the source material (24/96) determines the finial size opus?
Did you copy over a very large embedded artwork?

 
SimplePortal 1.0.0 RC1 © 2008-2019