HydrogenAudio

Hi

I recently decided to start using Opus for lossy compression.
Why ? I used Ogg Vorbis on Windows for years, and I am now on linux. I didn't find any build of the aoTuV encoder I used on Windows, nor managed to compile it myself. This got me to look for a more recent codec (Vorbis is old, there should be something better today). So, here I am  :))

Here is my problem, though : I want to be able to convert albums in FLAC (multiple files, as I need to play them on my stereo which doesn't support img+cue) to Opus, like I used to do with Vorbis, but I realized that the gapless is not perfect with Opus.
More exactly, the gapless is perfect but the glitchness isn't (as explained in this post (https://hydrogenaud.io/index.php/topic,97051.msg809016.html#msg809016)).

I realized that with one album with a continuous sound between tracks 1 & 2 : I hear a glitch with Opus, that I don't hear with FLAC.

The post (https://hydrogenaud.io/index.php/topic,97051.msg809016.html#msg809016) I mentioned before suggests that encoding files one by one to opus will necessarily induce glitches. But opusenc only supports one file at a time, and doesn't seem to work from a cue sheet.

So, what would you suggest ?
I started to think of a solution like : FLAC files > temporary FLAC single file > temporary Opus single file > Opus files
But I don't see how to get this workflow going (and maybe there is a more direct way).

Should I get back to Vorbis ?

Thanks !

a) https://hydrogenaud.io/index.php/topic,113498.0.html

OR:

b) If your input files are 44.1 kHz: try to resample to 48kHz before encoding:
FLAC input files > temp. 44.1kHz  single file > temp. 48kHz  single file > temp. 48kHz  multiple files > Opus files

Hi

Thank you lvqcl for your answer !

I tried what you suggested, but it doesn't seem to work :
If I split a temporary 48kHz file, I get a bad splitting (doesn't correspond to actual tracks). I got this by splitting to flac files, or directly to opus files with on-the-fly encoding. I used shnsplit for this.

I also tried to directly cut a single 44.1kHz flac file to opus files (again with on-the-fly encoding) : the splitting is correct, but I still get the glitch !

I should try to cut opus file after encoding with ffmpeg (like suggested by the post you mentioned), but how could I do this using a cue sheet ?
One other thing : how could I transfer tags from my initial flac files to the final opus files ? I loose them as soon as I create a single file ...

I am really starting to think I will give up with Opus. Am I really the only one having this issue ? Or maybe caring about it ?

Thanks

What version of the Opus encoder are you using?

Am I really the only one having this issue ? Or maybe caring about it ?

I also found that opus can add audible glitch between gapless tracks. Even if files are resampled to 48 kHz before encoding. Also there is highpass filter (https://hydrogenaud.io/index.php/topic,116127.0.html). I never tried to split opus files.
Here  are samples (In this case files were not resampled to 48 kHz before encoding to opus).
File "Image.wav": source files encoded to opus (1.3-rc-1, --bitrate 256), then opus files are decoded by foobar2000 and merged
File "Image sox.wav": source files were merged, then resampled to 48 kHz by foobar2000 with SoX resampler plugin.
Source files and opus files are also included.
https://drive.google.com/open?id=15v-cpPR207V3hzL0zE7kxabZtGW57YbH (https://drive.google.com/open?id=15v-cpPR207V3hzL0zE7kxabZtGW57YbH)
ABX log Spoiler (click to show/hide)

There's actually a library (libopusenc) that can do sample-accurate perfect glitchless (you could split a song in 1 millisecond chunks and still not hear anything wrong), but right now I'm not aware of a tool using it.

A critical problem with opus is the single entry for a replaygain-like value.  No separate track and album values, just the one, and no way to say if it is track, or is album, or is who knows what.  It defaults from what I've seen to 5 dB (from memory, and I suppose that is minus 5 dB) regardless the source.  If you use something else to calculate a replaygain value, that value is stuffed into the single entry available for an opus track.  It's not a tag, like replaygain is in .ogg, or .mp3, but a little cubbyhole for that value.  It's a disaster since there's no telling what the value is for (album or track), and if you go by the opus docs, it's required to be used.

FWIW, even if you have already adulterated the track with a replaygain scanner, the player in the link below plays opus tracks gaplessly ("no glitches" by definition then), but you have to remember to keep RG off (using the RG button).  Still, this is one reason I can't take opus seriously for music because RG is important.  It needs both track and album RG-value slots.

The last one on this page

https://hydrogenaud.io/index.php/topic,100209.0.html

Point is, check that a rogue RG value isn't in the tracks you play.  That will cause audio glitches as the level goes up or down.

Recent Foobar versions have a configurable advanced setting for ReplayGain in Opus. The program can either store it in the global gain header field or a tag, it can also clear the header gain field. Album gain written to the global gain field, as happened by default in the past, wouldn't cause sudden jumps in amplitude, since the gain would be the same for all tracks. Glitches due to changing track gain happen in all formats. There was a proposal by Frank Klemm for a gradually changing AGC type of track gain, but it was never implemented.

For music with extreme sub-bass, either sourced from vinyl or artifical electronic music, you could prefilter it with a highpass filter, so that the mandatory Opus HPF does very little. This is far from ideal, but is one way of addressing the issue.

Hi
Thank you all for your answers !

I'm getting a little lost with all this ...  :)
I don't know if the problem comes from replaygain or the Opus codec itself.
The thing is, changing the software for playing Opus files is not possible for me : my lossy files are for my DAP (Sansa Fuze, running Rockbox v3.14)

What version of the Opus encoder are you using?

I use the default version available in ubuntu repositories : opus-tools 0.1.10 (using libopus 1.2.1).

There's actually a library (libopusenc) that can do sample-accurate perfect glitchless (you could split a song in 1 millisecond chunks and still not hear anything wrong), but right now I'm not aware of a tool using it.

Is that this one ?
https://github.com/xiph/libopusenc
If so, will compiling this source code give me a different opusenc solving my issue ? Or just a library that I should use in my own custom opusenc ? (no idea how to do it, though)

Thank you !

Can you post a short clip of the source audio where a glitch occurs after converting to Opus? Let's say, 20 seconds from one track and 10 seconds of the following track.

Every time there's a gapless/glitchless discussion I point out to this example (https://hydrogenaud.io/index.php/topic,81991.msg716229.html#msg716229). Opus, MP3 and AAC all produce an audible glitch, the only exception is Vorbis.
I never tried with anything except the "default" encoders and settings, though.

A critical problem with opus is the single entry for a replaygain-like value.  No separate track and album values, just the one, and no way to say if it is track, or is album, or is who knows what.  It defaults from what I've seen to 5 dB (from memory, and I suppose that is minus 5 dB) regardless the source.  If you use something else to calculate a replaygain value, that value is stuffed into the single entry available for an opus track.  It's not a tag, like replaygain is in .ogg, or .mp3, but a little cubbyhole for that value.  It's a disaster since there's no telling what the value is for (album or track), and if you go by the opus docs, it's required to be used.

FWIW, even if you have already adulterated the track with a replaygain scanner, the player in the link below plays opus tracks gaplessly ("no glitches" by definition then), but you have to remember to keep RG off (using the RG button).  Still, this is one reason I can't take opus seriously for music because RG is important.  It needs both track and album RG-value slots.

The last one on this page

https://hydrogenaud.io/index.php/topic,100209.0.html

Point is, check that a rogue RG value isn't in the tracks you play.  That will cause audio glitches as the level goes up or down.

Given that almost everything written here is incorrect, I don't have great faith in the player that is being touted.

There are problems with gapless playback from most lossy codecs, not due to any "gap" but due to the nature of the encoding.  Opus certainly suffers because the audio from one frame is dependent on the audio of surrounding frames.  When you separate them into different tracks, the audio in the first/last frame is no longer encoded with reference to the surrounding frames.  So there is no actual gap between the tracks on playback but there is a glitch in the audio.

As mentioned, there are facilities in libopusenc for encoding tracks without this audio glitch but they aren't being used in any of the encoders that I know of.  It's worth mentioning that the glitch is usually not noticeable.  Still would be good to check the tracks the OP has a problem with to confirm the actual problem.

I can hear a faint puff in the left channel in the linked Marillion sample in a 192 kbit/s Opus 1.2.1 encode. But only on headphones at loud, probably unsafe level. The click gets much fainter at 256 kbit/s. This clip has the lowest frequency at around 50 Hz, so the issue with highpass I raised earlier doesn't apply. But we don't know the OP's samples yet.

I tried to ABX 192 and 256 kbit/s concatenated with Foobar multi-track decode feature without any dsp at 48 kHz.

Spoiler (click to show/hide)
Powerful music. I will try to listen to the album in following days. Thank you for this discovery.

Hi all

Many thanks for your interest in my topic !

Here are the 2 samples : last 10 seconds from track 1 and first 10 seconds from track 2.
They are the first 2 tracks of the album Amplifier Worship, from the japanese band Boris.

The glitch is very easy to ear (at least with decent headphones). I first noticed it with 128 kbps Opus, and still ear it the same after re-encoding at 256 kbps. The bitrate doesn't seem to have anything to do with it.

Is it supposed to sound like a bee trapped in a jar? 

I can't hear any significant glitch with this sample. The click is blends in with the nasty noise. Strangely, upsampling with SoX makes the click slightly bigger compared to a direct encode, letting opusenc.exe do the upsampling. I can hear it in the 48k sourced encode, as a short hiss impulse on the right side, but it still seems acceptable for a lossy encode, and not noticable without focusing on the position. No bass content in this sample either.

Perhaps the player isn't fully gapless?

I will delete these attachments soon as they don't show anything special.

A better encoder, which is aware of the contents of the previous track, would be nice to have.

The glitch is very easy to ear (at least with decent headphones). I first noticed it with 128 kbps Opus, and still ear it the same after re-encoding at 256 kbps. The bitrate doesn't seem to have anything to do with it.

It may depend on how the encoding and/or decoding is done. What happens if you manually convert your files to 48 kHz before encoding? What may be happening here is that if the original is 44.1 kHz and gets resampled for encoding, but gets "stitched back" at 48 kHz, then there may be a fractional sample extra/missing.

I'm the same, not seeing anything like what is being described.  Seems like something going on with the specific encoding or decoding that I'm not doing here.  Or I'm deaf!

Hi

I can't hear any significant glitch with this sample. The click is blends in with the nasty noise. Strangely, upsampling with SoX makes the click slightly bigger compared to a direct encode, letting opusenc.exe do the upsampling. I can hear it in the 48k sourced encode, as a short hiss impulse on the right side, but it still seems acceptable for a lossy encode, and not noticable without focusing on the position. No bass content in this sample either.

Perhaps the player isn't fully gapless?

Still pretty noticeable to me on your opus files.
In fact, I noticed this problem when listening to this album in the bus, and not focusing at all on the transition itself. The sound is supposed to be continuous between tracks, but this "click" really annoyed me.

As for the gapless capability of the player, I use Audacious on Linux for testing the samples (no idea if it is perfectly gapless) and Rockbox on my DAP (I know it is perfectly gapless).
Anyhow, I should have mentioned that I don't hear the glitch when playing the flac files, but only when playing the opus encoded files : it is not due to the player.

It may depend on how the encoding and/or decoding is done. What happens if you manually convert your files to 48 kHz before encoding? What may be happening here is that if the original is 44.1 kHz and gets resampled for encoding, but gets "stitched back" at 48 kHz, then there may be a fractional sample extra/missing.

Resampling to 48kHz before encoding doesn't change anything. In fact, it seems that the glitch is even more important by doing that, like j7n said (just a subjective feeling, though  :D)

I'm the same, not seeing anything like what is being described.  Seems like something going on with the specific encoding or decoding that I'm not doing here.  Or I'm deaf!

Did you try with good headphones ? I tried with my Philips Citiscape Uptown and my Focal Listen : it's very easy to ear with both of them.

Fundamentally, Opus and Vorbis use exactly the same mechanism to handle gapless. libopusenc provides a way to make perfectly glitchless gapless, but in normal use with opusenc, it should at least be on par with Vorbis. That being said, it's possible there's either a bug in the code or in the way you're using opus-tools. To figure that out, it would help if you could provide a way to reproduce the problem. That would mean providing:

• Two 48 kHz wav files that are supposed to be played consecutively (let's not go to 44.1 kHz for now)
• Two corresponding .opus encoded files (using opusenc)
• The two decoded opus files as wav (using opusdec)
• The same (.ogg and decoded wav) for Vorbis

Make sure you use opusenc and opusdec. All the gapless handling is done by the actual tools rather than the Opus library and not all encoders and decoders are going a good job at gapless.

Quote from: jmvalin on 2018-09-19 23:15:48

There's actually a library (libopusenc) that can do sample-accurate perfect glitchless (you could split a song in 1 millisecond chunks and still not hear anything wrong), but right now I'm not aware of a tool using it.

Is that this one ?
https://github.com/xiph/libopusenc
If so, will compiling this source code give me a different opusenc solving my issue ? Or just a library that I should use in my own custom opusenc ? (no idea how to do it, though)

Thank you !

In short, probably not.  opusenc has only recently been converted to use the external library.  Check your version, I think 0.2 was the first to use libopusenc.  Or you could just check the libraries that your opusenc binary is linking to.  You shouldn't need to recompile anything, if you have that version you'll already be using the best available encoding method.  If you have an older version then it won't be using libopusenc at all, so recompiling will change nothing.

Resampling to 48kHz before encoding doesn't change anything. In fact, it seems that the glitch is even more important by doing that, like j7n said (just a subjective feeling, though  :D)

Just realized that libopusenc has a gapless bug which means opus-tools 0.2 is affected (it's the first version to use libopusenc). Have you tried with previous versions of opus-tools?

Hi

Fundamentally, Opus and Vorbis use exactly the same mechanism to handle gapless. libopusenc provides a way to make perfectly glitchless gapless, but in normal use with opusenc, it should at least be on par with Vorbis. That being said, it's possible there's either a bug in the code or in the way you're using opus-tools. To figure that out, it would help if you could provide a way to reproduce the problem. That would mean providing:

• Two 48 kHz wav files that are supposed to be played consecutively (let's not go to 44.1 kHz for now)
• Two corresponding .opus encoded files (using opusenc)
• The two decoded opus files as wav (using opusdec)
• The same (.ogg and decoded wav) for Vorbis

I don't have any 48kHz file. All my files come from CDs, so I can only resample from 44.1 to 48kHz. And as I said before, resampling before encoding doesn't solve my problem.

Just realized that libopusenc has a gapless bug which means opus-tools 0.2 is affected (it's the first version to use libopusenc). Have you tried with previous versions of opus-tools?

I use the last version available in ubuntu repositories : opus-tools 0.1.10 (using libopus 1.2.1), so I'm not supposed to be affected by the bug you mentioned.

This is interesting to me. I've tried encoding your flac samples using the brand-new opus 1.3 release and a slight click is definitely audible to me (when playing through fb2k). As you said, the flac samples in comparison are pristine. It sounds like the click is coming slightly from the right channel, but I may be hallucinating that detail. Have you tried concatenating the tracks and encoding to opus to verify whether it's an artifact related to encoding or gapless playback?

The click is present only in the right channel so you aren't hallucinating. And just to be clear, foobar2000 isn't introducing the glitch. It's even louder when the files are decoded with opusdec.

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.

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?

Quote from: lithopsian on 2018-09-22 14:16:34

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.

The click is present only in the right channel so you aren't hallucinating. And just to be clear, foobar2000 isn't introducing the glitch. It's even louder when the files are decoded with opusdec.

I don't hear it hear.  See this upload.

https://hydrogenaud.io/index.php/topic,116756.new.html

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:
(https://i.imgur.com/ouarSml.png)

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?

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 (https://tools.ietf.org/html/rfc7845.html#section-5.2.1) 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

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.

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

And here i'm repeating test again. This time i use opus 1.3 final --bitrate 256   (build from 1st post in this thread (https://hydrogenaud.io/index.php/topic,116746.0.html)) 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 (https://hydrogenaud.io/index.php/topic,116127.0.html) 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 (https://www.dropbox.com/s/xgmsm9zef5gmhjr/opus%201.3%20gapless%20click.zip?dl=1)
ABX log:

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:
(https://i.imgur.com/EkKihv6.png)
...and opus  --bitrate 256 vs AAC FDK VBR 5
(https://i.imgur.com/yxyI0q9.png)

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.

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

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.

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

https://tools.ietf.org/html/rfc7845.html#section-4.2

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.

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.

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 (https://hydrogenaud.io/index.php/topic,116746.msg966119.html#msg966119)

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.

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.

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.

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.

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.

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

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.

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.

More testing: Vorbis introduces the same glitch, it's just way, way quieter so it's probably not going to be audible there.

How about my example? https://hydrogenaud.io/index.php/topic,116605.msg963796.html#msg963796 Glitch is much more audible there.

Conclusions so far from discussion with jmvalin:

1) The correct way to handle this is to do the split in libopusenc. This will be gapless and glitchless. Everything else is going to be some kind of workaround that can still fail for pathological samples.

2) The signal in this file behaves badly in digital filters when they assume the signal before/after they operate is 0 (this is the default). To prevent this, you need to extend the signal, for example with a simple LPC predictor. Opus does this for the *end* of files, but not at the start. (https://github.com/xiph/libopusenc/blob/master/src/opusenc.c#L1147) I confirmed by mixing the Vorbis and Opus encodes that it's the start of the second file that glitches, not the end of the first one.

3) This needs to happen in both the resampler and the encoder. Easiest would be to have the resampler always do it, and feed the extended output to the encoder.

4) Vorbis implements it also for the start of files (https://github.com/xiph/vorbis/blob/ea8b03fce93444cb3cf0131909e15b4f8856e863/lib/block.c#L416) which is why it behaves so well here. (And obviously it can't fail at the resampling step).

But why not implement extrapolation also for the start of file in opus, just like in vorbis? Or is it impossible without breaking something?

Guys, any news for fix it glitch? :'( Or OPUS no longer developing? :o

I didn't see anyone else using libopusenc for gapless encoding, so I did it myself.

Source code and usage instructions here. (https://github.com/Octocontrabass/opusgap)

Nice, that is indeed gapless as long as decoding doesn't use Opus' resampler. That can introduce glitches again.

Nice, didn't know how exactly this is done.
I think I'm going to try replicating something similar with python & ctypes...

Conclusions so far from discussion with jmvalin:

1) The correct way to handle this is to do the split in libopusenc.
...

Guys I know this is quite old thread but to be honest I must say I dont understand what does it mean.  Is there different algorithm used ? Could you please clarify?

The only way to guarantee a smooth transition is to combine all of the tracks into one big audio stream, encode the whole thing, and then split it back apart into separate files.

When you use libopusenc, you can tell it to split the encoded Opus stream into multiple files, and there will be no gaps or glitches at track boundaries.

Thank you! Now it is clear!

I have experimented with all this including Octocontrabass's code as 192 kbit/s listening test made me reconsider my stance on Opus (and ditch Vorbis):

1st off, opusenc does some tricks that ensures that the opus signal starts and ends where the start and the end samples are even w/o any knowledge of the previous and the following tracks. If I encode with opusenc each track one by one, it does appear gapless in Linux  on mpv media player and also on sox's play. Somewhere I read, that DeadBeef also works, but I have not tested it. However, mplayer and cmus both incorrectly decode so it is not.

However, I believe, one, indeed, needs to use libopusenc (i.e. opusenc) to get this and the next level of gapness. FFmpeg does not link with libopusenc, so it might not work well in the gapless department.

The libopusenc has a provision that Octocontrabass uses which is not documented, but the best description I found is at http://lists.xiph.org/pipermail/opus/2017-November/004047.html (albeit the bloke there is chasing something completely different). However, this quote describes this even better gapless-ness:

Essentially, the last frame of a file is marked as a "keyframe" by
disabling prediction for this frame in libopus. This encoded keyframe
frame is then copied in verbatim to the next file, with the pre-skip
set to the frame length. The encoder is not reset, and reading the
keyframe will bring the decoder to the correct state in which it is
able to correctly decode the following frames.

So it is not exactly how Octocontrabass describes, but it looks better than encoding each track indiviually. I have tested that code, and it does work, indeed. That will be my choice of encoding each track per album. You must only apply albumgain before encoding as if each tracks are amplified differently by track gain, you will have discontinuities.

I am studing libopusenc now and we could add this functionaly to opusenc so that we would pass all the tracks like
opusenc in1.wav out1.opus in2wav out2.opus
I started to do that, but opusenc is messy enough for me. I think I will just extend the opusgap for my needs. I prefer clean code to ensure reliability

PS: While I read opusenc it seemed that it assumes mono/stereo input only. No-one noticed? It seems quite a limitation. I hope I read it wrong.

PS: Albeit Opus looks like a great technology, but it is disheartening that opus library needs another layer, namely libopusenc, to be able to encode gaplessly. This is really a sign of haste and bad design. I do not understand what was the rush. But at least Jean-Marc Valin seemed to save the day at least with libopusenc, so I can consider Opus now. Again, gapless playback is essential.

So it is not exactly how Octocontrabass describes, but it looks better than encoding each track indiviually.

I did see that code in libopusenc, but I figured the details weren't especially important. ;) (I think it's possible to split the stream without a keyframe, but then you would need to copy more than one frame from the previous file, and I don't know how to figure out exactly how many frames you need.)

PS: While I read opusenc it seemed that it assumes mono/stereo input only. No-one noticed? It seems quite a limitation. I hope I read it wrong.

Are you talking about opusgap? I really only wrote it for myself, so it only supports the WAV files I want to encode with it. I can add support for more WAV formats if you can provide samples of the files you want to encode.

I think it's possible to split the stream without a keyframe, but then you would need to copy more than one frame from the previous file, and I don't know how to figure out exactly how many frames you need

One naive and yet bulletproof way is to iteratively try adding 1 more frame until the required slice starts decoding identically. But it will be pretty inefficient, especially if encoding a lot of short tracks.

The Opus decoder isn't defined to be bit-exact, so you might not copy enough frames to put every decoder in the same state that way. I'm not familiar enough with the format to come up with a better solution, though.

I just saw this thread; the only proper way to solve this seems to be for the player to not dump and create a new context for a new file, the way pretty much all decoders do. mp3/aac gapless works only because decoders will hold the context open from file to file, as long as they were encoded the same way, and some even did that for Vorbis, but it seems like everyone just punted for Opus, maybe since they don't want to deal with preroll frames. Due to that, I just use a 1-second crossfade and deal with it.

I just saw this thread; the only proper way to solve this seems to be for the player to not dump and create a new context for a new file, the way pretty much all decoders do.

No, the proper way to solve this is to encode your gapless audio using the gapless support in libopusenc. ;)

I have an example encoder a few posts up if you'd like to give it a try.

Err, more than three years have passed.
Proof of concept by @Octocontrabass makes it gapless, official Opusenc does not.
How to get the case off the ground?

How about my example? https://hydrogenaud.io/index.php/topic,116605.msg963796.html#msg963796 Glitch is much more audible there.

Have you tried opusgap on your example?

Err, more than three years have passed.
Proof of concept by @Octocontrabass makes it gapless, official Opusenc does not.
How to get the case off the ground?

Is there a directly correspeonding bug ticket or feature request on gitgub for libopus or opustools?

I don't see anything except this one, last reply in 2020 - maybe the title "Pre-skip doesn't include extra_samples" isn't very inspiring to work on it :-) https://github.com/xiph/opus-tools/issues/55#issuecomment-641603262

The gist is that with opusenc you're out of luck except for a rather major change to encode multiple tracks at once - personally, I'm sometimes confused by features of libopus (in active development) and opus-tools (nearly no development anymore).