Skip to main content
Topic: Opus ReplayGain / Gapless? (Read 1849 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus ReplayGain / Gapless?

Reply #25
There are no "hacks", no special hoops to jump through to make Opus play gapless, in the sense that there is no silence between one track and the next.  The way that it is encoded means that tracks can play back continuously without any tags or special processing.  libopusfile is a library that does this (more or less) automatically. Programs that don't use libopusfile are a little more complex to write and apparently some of them did not play back tracks gaplessly, but that could be considered a bug of the player.

The lossy processing that Opus uses means that the value of an encoded sample can depend on the value of several previous samples.  This does not automatically happen at the start of a track, so that there is potentially a small glitch in the audio between the last sample of one track and the first sample of the next.  This is not a gap as such and it isn't usually audible, or at least not noticeable.  The examples where it is audible are not exactly typical music.  This isn't an issue which is unique to Opus, but its LPC and built-in resampling mean it can be much more significant in Opus.  I went through half a dozen gapless albums tonight and couldn't spot any glitches.

libopusenc is a relatively new library for encoding that includes functions to encode the start of one track relative to the end of the previous track so that there is no such glitch.   To do that special processing it must be aware that the two tracks are "continuous", so the input tracks cannot be handled as separate files.  opusenc in opus-tools 0.2 uses libopusenc, but only processes individual files so not much help.  I'm not sure that there any issues left when the tracks are encoded using the correct LPC extension code from libopusenc, but that's a moot point if there are no encoders doing it.  Maybe I'm missing something?

Re: Opus ReplayGain / Gapless?

Reply #26
There are no "hacks", no special hoops to jump through to make Opus play gapless, in the sense that there is no silence between one track and the next.  The way that it is encoded means that tracks can play back continuously without any tags or special processing.  libopusfile is a library that does this (more or less) automatically. Programs that don't use libopusfile are a little more complex to write and apparently some of them did not play back tracks gaplessly, but that could be considered a bug of the player.

The lossy processing that Opus uses means that the value of an encoded sample can depend on the value of several previous samples.  This does not automatically happen at the start of a track, so that there is potentially a small glitch in the audio between the last sample of one track and the first sample of the next.  This is not a gap as such and it isn't usually audible, or at least not noticeable.  The examples where it is audible are not exactly typical music.  This isn't an issue which is unique to Opus, but its LPC and built-in resampling mean it can be much more significant in Opus.  I went through half a dozen gapless albums tonight and couldn't spot any glitches.

libopusenc is a relatively new library for encoding that includes functions to encode the start of one track relative to the end of the previous track so that there is no such glitch.   To do that special processing it must be aware that the two tracks are "continuous", so the input tracks cannot be handled as separate files.  opusenc in opus-tools 0.2 uses libopusenc, but only processes individual files so not much help.  I'm not sure that there any issues left when the tracks are encoded using the correct LPC extension code from libopusenc, but that's a moot point if there are no encoders doing it.  Maybe I'm missing something?

Ok I understand. What you're describing would be unavoidable with any lossy codec that encodes music files separately.

If the second-to-last, third-to-last, samples / frames of a song are very different in amplitude from the last sample / frame, when the next song plays, there will be a spike in amplitude audible as a minor 'glitch'.

So the solution you're suggesting is having libopusenc look at surrounding tracks on the encoder, when it's the same album. Can we expect opus-tools to implement this at some point?


Honestly at this point it's like looking for needles in a haystack. I only believe it doesn't happen on Vorbis because you tell me so, cuz this phenomena is just a natural result of lossy encoding. Shouldn't be a problem with most mastered albums. That older topic had someone point out it occurs in Vorbis too, just less noticable.

You could, if it really bothers, play the audio in lossless format. Or, put a very small fade-in / fade-out on the audio player (a few ms) between tracks, it'll still respect the BPMs of the audio stream. Or, encode the full album as a single track with CUE bookmarks.

Maybe forcing 2.5 ms frame size improves it.

Re: Opus ReplayGain / Gapless?

Reply #27
The Opus Tools already encode the first frame by priming both the resampler (if used) and part of the first frame itself with linear predictor output going backwards from the input samples. Technically, it should also be padding the end of the file with such.

Vorbis already does this transparently in the libvorbisenc library, and handles decoding and cutting out the priming samples in the libvorbisfile decoding library.

Opus does it in the encoder tool, and any best effort decoder which handles the delay field and truncates the end of the stream by the granule position values, should already handle this automatically. libopusfile, while it came late, just makes this easier and transparent to the application using it.

Re: Opus ReplayGain / Gapless?

Reply #28
The Opus Tools already encode the first frame by priming both the resampler (if used) and part of the first frame itself with linear predictor output going backwards from the input samples. Technically, it should also be padding the end of the file with such.

Vorbis already does this transparently in the libvorbisenc library, and handles decoding and cutting out the priming samples in the libvorbisfile decoding library.

Opus does it in the encoder tool, and any best effort decoder which handles the delay field and truncates the end of the stream by the granule position values, should already handle this automatically. libopusfile, while it came late, just makes this easier and transparent to the application using it.

That's amazing! Then the issue sould be entirely resolved

Re: Opus ReplayGain / Gapless?

Reply #29
Absolutely nothing has changed in Opus since the glitch has been reported. I just downloaded latest code from Git and compiled fresh opusenc and opusdec. Converted b1.flac and b2.flac to Opus with default settings and decoded to wav. The resulting files have the exact same transition glitch.

Re: Opus ReplayGain / Gapless?

Reply #30
@Case : Although I assume that you made an exact 20 seconds snippet so that the 480000 sample should be the exact half, the graphic that you show doesn't exactly map my experience in that other thread, because your graphic shows the cut in the middle of the ressonating change (that small sinus added), while in my case the ressonation was entirely on the beginning of the second sample.
Can you verify your test?


Re: Opus ReplayGain / Gapless?

Reply #31
the graphic that you show doesn't exactly map my experience in that other thread, because your graphic shows the cut in the middle of the ressonating change (that small sinus added), while in my case the ressonation was entirely on the beginning of the second sample.
Do you mean this - https://hydrogenaud.io/index.php?topic=116605.msg963847#msg963847 ? But you used sample from me ( https://hydrogenaud.io/index.php?topic=116605.msg963796#msg963796 ), right? @Case used sampe from topic starter - https://hydrogenaud.io/index.php?topic=116605.msg962561#msg962561

Re: Opus ReplayGain / Gapless?

Reply #32
Yes, I see it's a different sample, but it should still affect only the new sample, not half of the end of first and half of the start of second

Re: Opus ReplayGain / Gapless?

Reply #33
Best to stick to lossless rips, then. And stuff maybe MP3 or Vorbis on your mobile device.

Re: Opus ReplayGain / Gapless?

Reply #34
@kode54 This is not about ideal world.
This is if Opus is capable of doing something that other lossy codecs are able to. It was also compared with Vorbis and was seen that Vorbis had this too, but much more attenuated, so it wasn't audible.

Re: Opus ReplayGain / Gapless?

Reply #35
The padding method of attempting to fix gaplessness probably won't work so well with Opus, due to its low latency design.

Re: Opus ReplayGain / Gapless?

Reply #36
I've seen the glitch I think. It's an anomaly on the first few samples of the intro to the second track. It does not correspond to linear prediction of nearby samples. It does not improve by lowering or increasing the frame size.  It does not show on the vorbis encode.
Tracks from Rollin
Encoded with latest libopus --bitrate 160


Re: Opus ReplayGain / Gapless?

Reply #37
@Case : Although I assume that you made an exact 20 seconds snippet so that the 480000 sample should be the exact half, the graphic that you show doesn't exactly map my experience in that other thread, because your graphic shows the cut in the middle of the ressonating change (that small sinus added), while in my case the ressonation was entirely on the beginning of the second sample.
Can you verify your test?
I just verified the end of the decoded b1.wav file, it does have ripple at the end. Remember that these are also affected by Opus' resampler.

Re: Opus ReplayGain / Gapless?

Reply #38
Ah yes, the resampler. It would probably help if the encoder padded the resampler with more than just enough to meet its latency. I was under the possibly mistaken impression that padding with a linear predictor was supposed to counter this sort of behavior. I guess it also depends on how the resampler is used?

 
SimplePortal 1.0.0 RC1 © 2008-2020