Skip to main content ↑ ↓
Topic: Opus gapless and glitchness encoding (Read 3264 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus gapless and glitchness encoding

Reply #25 –
I'd like to see internal support for encoding to Opus in Foobar, which would process an album as a continuous stream and use the libopusenc library directly, maybe guessing an album by a tag pattern like during RG scanning. An out of the box, fully gapless support in Foobar, unlike with other codecs, might slightly promote the status of Opus as the current standard.

It seems that the issue can't be completely solved with a command-line encoder, except maybe with a hack where a fraction of a second of data is saved in a temporary location and prepended when encoding the following track. And this can't work reliably when encoding multiple files simultaneously, and it won't prevent the transition click from bleeding backwards. A file splitter that requires typing into the console isn't a solution either for daily use.

Re: Opus gapless and glitchness encoding

Reply #26 –
Quote from: lithopsian on
Given that almost everything written here is incorrect

Given your precision...I find your claim lacking.

My point was very to the point.  It stands by itself why opus can't be considered for music tracks (re: album play and general single play - pick album gain for the gain to use and consider yourself lucky enough).  You can start here.

https://www.ietf.org/mail-archive/web/codec/current/msg02944.html

as a mid-way point.  If I come to find specifics in the source (it's been a long while since I looked at it) I may update here.  jmvalin made a comment about fb2k doing something on its own.  It's not in the opus spec.  The spec (as I remember, and from reading Monty's very-old-now comments, about opus) looks like opus was intended for video/web play, not music album play.  Microsoft in newer Windows 10 also looks to be using it only for web play (the browser, for audio of videos using opus).

Point is, if it can't do replay-gain right, it won't sound gapless when using RG.  Not even close.  Dismiss RG if you want.  I can't.  And what exactly is your problem with this now?

Re: Opus gapless and glitchness encoding

Reply #27 –
Quote from: 40th.com on
Quote from: lithopsian on
Given that almost everything written here is incorrect

Given your precision...I find your claim lacking.

My point was very to the point.  It stands by itself why opus can't be considered for music tracks (re: album play and general single play - pick album gain for the gain to use and consider yourself lucky enough).  You can start here.

https://www.ietf.org/mail-archive/web/codec/current/msg02944.html

as a mid-way point.  If I come to find specifics in the source (it's been a long while since I looked at it) I may update here.  jmvalin made a comment about fb2k doing something on its own.  It's not in the opus spec.  The spec (as I remember, and from reading Monty's very-old-now comments, about opus) looks like opus was intended for video/web play, not music album play.  Microsoft in newer Windows 10 also looks to be using it only for web play (the browser, for audio of videos using opus).

Point is, if it can't do replay-gain right, it won't sound gapless when using RG.  Not even close.  Dismiss RG if you want.  I can't.  And what exactly is your problem with this now?

Still wrong.  Go back and read the spec, then come and post a sensible comment.  Album replaygain is fully supported in Opus, even if support in third-party players is (at best!) patchy.

Re: Opus gapless and glitchness encoding

Reply #29 –
It's still there. Try with headphones and you have to have volume quite high. I see in the spectrogram that it's actually not only on the right channel but the error in the left channel is much quieter:

Re: Opus gapless and glitchness encoding

Reply #30 –
Quote from: Case on
It's still there.
I see a picture.  Anyway, if the idea here is that because of no overlap with a previous sample window you get this, then you get this with mp3, aac, vorbis.

How loud?  I imagine the headphone driver will break up more than anything.  I used headphones and heard nothing.  I also did fb2k 1.4 and heard nothing.  I turned the volume higher than I wanted and heard nothing, not at the b1/b2 transition.  I heard one artifact elsewhere, though.  Almost like a hot mic picking up aaaa pin drop (b1, around 1-sec mark).

You may have a TOS-violation-free picture there (j/k), but that doesn't mean that is audible.  Headphone driver(s) breaking up are much more likely.  Lame/itunes/oggenc results in what for these?  Is the original .flac around?

Re: Opus gapless and glitchness encoding

Reply #31 –
The original implementation for replaygain in opus would not cause clicks as the album gain would be used by default. It did cause playback to be 5 dB lower outside of Foobar going against the ca. -18 dB RG standard established for over 10 years, and even earlier as it approximately matches levels on old CDs too. The header gain isn't even supposed to be at R.128, and could be chosen freely. But that is in the past as now R128_ALBUM_GAIN can be used, at the expense of compatibility with players that don't support it, which the original method gave for free – but at wrong reference level.

Opus is quite a bit worse than other codecs in gaplessness with flawed source material with low frequency osscillations or DC offset. Those are errors that should be fixed at the source, if they are noticed. But it would be nice if a fully gapless Opus encoder (in Foobar or similar GUI program) could deal with this and the same time improve the samples by filtering the DC.

http://i.imgur.com/yC6yCmI.png
http://i.imgur.com/7SvoeJ2.png

Re: Opus gapless and glitchness encoding

Reply #32 –
Quote from: 40th.com on
You may have a TOS-violation-free picture there (j/k), but that doesn't mean that is audible.  Headphone driver(s) breaking up are much more likely.  Lame/itunes/oggenc results in what for these?  Is the original .flac around?

I have tin ears, but the click is quite audible in the files (both wav and opus) provided in your zip. It occurs right after the transition to the second track. I'm using AKG 701 headphones, at a relatively high volume, but not ridiculously loud. Anyone should be able to hear it with a bit of concentration. Please pay attention to the original FLACs, maybe you are mistaking the click for part of the natural sound.

Re: Opus gapless and glitchness encoding

Reply #33 –
Quote from: 40th.com on
You may have a TOS-violation-free picture there (j/k), but that doesn't mean that is audible.  Headphone driver(s) breaking up are much more likely.  Lame/itunes/oggenc results in what for these?  Is the original .flac around?
My post should make you happy about TOS (although i used other files) - https://hydrogenaud.io/index.php/topic,116605.msg962454.html#msg962454

Re: Opus gapless and glitchness encoding

Reply #34 –
And here i'm repeating test again. This time i use opus 1.3 final --bitrate 256   (build from 1st post in this thread) with 48 kHz source files which are pre-highpassed in Audacity (Nyquist highpass filter: 10 Hz, 48 dB per octave) (source file was highpassed, then split  to tracks, so no clicks due to highhpass). So we can be sure that reason of click is not highpass filter in opus and even not resampler.
file "Image orig.wav": original files "01. Track number 1 16.wav" and "02. Track number 2 16.wav" merged using fb2k
file  "Image opus.wav": files "01. Track number 1.opus" and "02. Track number 2.opus" decoded with opusdec (all default settings) and then merged with fb2k
Original files "01. Track number 1 16.wav" and "02. Track number 2 16.wav" are included.
https://www.dropbox.com/s/xgmsm9zef5gmhjr/opus%201.3%20gapless%20click.zip?dl=1
ABX log:
Code: [Select]
foo_abx 2.0.5 report
foobar2000 v1.4.1 beta 4
2018-10-20 19:31:09

File A: Image opus.wav
SHA1: 6a1e46fde0d28c1da87f39d1bedfa1b1b4a1cd7d
File B: Image orig.wav
SHA1: 23c6125471838ee6b21370e5962863edd3a0f473

Output:
WASAPI (event) : Интерфейс SPDIF (4- DR.DAC2 DX USB), 24-bit
Crossfading: NO

19:31:09 : Test started.
19:33:24 : 01/01
19:34:06 : 02/02
19:34:31 : 03/03
19:34:56 : 04/04
19:35:20 : 05/05
19:36:06 : 06/06
19:36:30 : 07/07
19:37:17 : 08/08
19:37:41 : 09/09
19:38:40 : 10/10
19:39:06 : 11/11
19:39:30 : 12/12
19:40:05 : 13/13
19:40:50 : 14/14
19:41:36 : 15/15
19:42:02 : 16/16
19:42:02 : Test finished.

 ---------- 
Total: 16/16
Probability that you were guessing: 0.0%

 -- signature -- 
9be003653fbd55dd92a92e8df13ea4c7a72069ba

Additionally, here is comparison how transition point looks in opus --bitrate 256 vs vorbis -q8:

...and opus  --bitrate 256 vs AAC FDK VBR 5

Re: Opus gapless and glitchness encoding

Reply #35 –
In this case, it is much more clear to show the samples rather than the spectogram to understand the "click". See attachment.

The problem is actually not in the junction between both tracks, but actually on the content of the second track.
If we look at it, the first 5 samples are the worst, but we could say that up to the first 32 samples contain an harmonic that shouldn't be there. (Maybe more, but since this is lossy coding, I can't be sure what comes from the codec itself and what comes from the "click")

It is reasonable to say that the codec cannot adapt fast enough from DC to the cut place and the filter causes that oscillation. I don't know if this could require work on the decoder, on the encoder or both and to which extent this could be worked out.  I checked to see if framesize made any difference and while it did, it was minimal. Reducing the bitrate to 48 had a greater impact.

Re: Opus gapless and glitchness encoding

Reply #36 –
Hi

Thank you all for all your replies ! Glad you're interested in the topic.
In the meantime, I switched back to Vorbis, which works great. I will keep trying with future versions of Opus, hoping this issues gets corrected some day.

PS : I realize that I wrote "glitchness" instead of "glitchless", in the title and the first message, and it doesn't make any sense :) Could an admin change it, for archiving purpose ? Thanks

Re: Opus gapless and glitchness encoding

Reply #37 –
So, if one wants to use Opus in true gapless way then it's necessary to encode a complete album in one go, and only split after encoding? That's unfortunate...
I'll probably try to  do some script for doing this just for science. (Doing it by hand would be extremely tedious)

Just tested a bit, seems like ffmpeg can't split Opus files exactly, even if I round track transition points to 20 ms, either I need to find some less obvious ways to make it not lose any samples or use a different tool or... maybe study Opus format and go full DIY.

Re: Opus gapless and glitchness encoding

Reply #38 –
After closer examination it seems ffmpeg loses exactly 312 samples in between, which is signalled encoder delay, so maybe it's possible to fix it somehow by changing some options related to timestamps or something...

Re: Opus gapless and glitchness encoding

Reply #39 –
https://tools.ietf.org/html/rfc7845.html#section-4.2
Quote
The 'pre-skip' field MAY also be used to perform sample-accurate
   cropping of already encoded streams.  In this case, a value of at
   least 3840 samples (80 ms) provides sufficient history to the decoder
   that it will have converged before the stream's output begins.
now I think I kind of get the idea how it should be done
what I still don't get is which existing software is able to crop Opus stream like that,
and if it's even a good idea to try to make ffmpeg do this

maybe it's simpler to just convert stuff to single Opus file + CUE, and live with it, this however won't work good with players which don't understand CUE or where it's not straightforward to deal with them.

Re: Opus gapless and glitchness encoding

Reply #40 –
The bug that Jean-Marc spotted in libopusenc has been fixed in v0.2.1.  It caused a one-sample glitch at the supposedly seamless transition.  No idea if this is what you were seeing (hearing) or not.
 
SimplePortal 1.0.0 RC1 © 2008-2018