Skip to main content ↑ ↓
Topic: Opus gapless and glitchness encoding (Read 4706 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.
Keep calm and opusenc --bitrate 128

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...
Keep calm and opusenc --bitrate 128

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.
Keep calm and opusenc --bitrate 128

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.

Re: Opus gapless and glitchness encoding

Reply #41 –
Quote from: lithopsian on
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.
So problem discussed in this topic is not caused by those bug. Problem is still reproducible with recent build from this post

Re: Opus gapless and glitchness encoding

Reply #42 –
I had a discussion with jmvalin about this issue last time we met, but there was some uncertainty regarding the tools used to encode or decode, exact versions with or without latest fixes etc, so I had a closer look.

I compiled the latest master (21st Jan 2019) of all opus related tools (libopus, libopusenc, libopusfile):
opusenc opus-tools 0.2-3-gf5f571b (using libopus 1.3-10-gf5790833)
Copyright (C) 2008-2018 Xiph.Org Foundation

Encoded both files with opusenc, decoded with opusdec, and stitched together with sox.

The result is here:
https://sjeng.org/ftp/work/b12_opus.wav

I cannot hear a glitch in this file. The file is a bit weird which makes listening tricky. If I increase the volume too much, my Sennheisers start reverberating, and played with speakers there's too much inter-modulation going on.

That said, a closer look at the file reveals that a) there is indeed a sort of glitch b) it becomes obvious why I can't hear it. See attached image. The glitch is very high up in the frequency range, from 18kHz to about 22kHz.

I'm not clear what causes it. The position in the spectrum doesn't exclude the resampler, I think.

Re: Opus gapless and glitchness encoding

Reply #43 –
it looks like it not completely limited to 18..22 kHz, there's *something* visible from about 6 kHz but it's very quiet.
maybe it could be possible to hear it on some other tracks.
Keep calm and opusenc --bitrate 128

Re: Opus gapless and glitchness encoding

Reply #44 –
Quote from: magicgoose on
it looks like it not completely limited to 18..22 kHz, there's *something* visible from about 6 kHz but it's very quiet.

Yes, but it's an audio codec, not an image compressor so if it's below the audible threshold it's irrelevant. I pointed out the >18kHz part because that is much louder, not present in the original, probably audible to others who can hear higher up the spectrum, and may explain why some people reported hearing the problem and others do not.

Quote
maybe it could be possible to hear it on some other tracks.

If it is correlated to signal amplitude, which is the typical case, it's not going to be.

I'm going to try to eliminate the re-sampler as the origin.

Re: Opus gapless and glitchness encoding

Reply #45 –
My observations with Opus 1.3 and various audio players:

These players seem to handle gapless playback fine (I don't know if it's perfect or not): foobar2000, Quod Libet, cmus.
These are producing audible glitches: Rockbox, Audacious, Qmmp, MPD + Cantata.

Re: Opus gapless and glitchness encoding

Reply #46 –
Pre-resampling everything with Sox doesn't change the result. So it's not a resampler issue.

Re: Opus gapless and glitchness encoding

Reply #47 –
Quote from: Garf on
Pre-resampling everything with Sox doesn't change the result. So it's not a resampler issue.

Actually, it turns out that the resampled files have this glitch *before* encoding to Opus. So this isn't an opus codec problem, it's bad behavior of the resampling in both opus-tools and sox.

Re: Opus gapless and glitchness encoding

Reply #48 –
And more looking around turns out that even if the files are pre-resampled correctly, encoding+decoding to Opus will re-add a similar glitch.

Re: Opus gapless and glitchness encoding

Reply #49 –
More testing: Vorbis introduces the same glitch, it's just way, way quieter so it's probably not going to be audible there.
 
SimplePortal 1.0.0 RC1 © 2008-2019