Quote from: Deathcrow on 2018-10-01 22:17:04

Quote from: mudlord on 2018-10-01 22:09:42

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.

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.

#!/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 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?

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.

• 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.

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

Quote from: jmvalin on 2018-10-04 02:00:12

• 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.

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.

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

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.

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?

(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?