I heard Android now natively supports the Opus codec. I've been using Vorbis for many years. I'd like to know if the issues with music playback have been solved with Opus?
Mainly, does ReplayGain now work with Opus? I'd be using the latest foobar2000 to attach the ReplayGain track / album info onto the Opus files. I don't mind if it does it through some ReplayGain tag or changing the file header, as long as it works on my phone.
And also, does gapless work now in Opus? Got some albums that don't make sense without proper gapless.
If you have the answers that would be swell. Thank you!
Haven't heard anything about fixing gapless encoding in Opus.
Theoretically it's possible if you encode an album as 1 stream and then split it without transcoding - but I'm unsure if there's a tool which can do that properly. (IIRC it's not so simple because in a middle of a stream an Opus packet requires a few previous packets to be decoded accurately)
I've been using Opus on my Android for quite some time, even testing the Poweramp when they added support for it. Opus supports only track gain, and I didn't notice any problems with gapless playback. But when listening to whole albums, I turn off Replaygain because it's not needed. I use it only for self-made compilations.
Haven't heard anything about fixing gapless encoding in Opus.
Theoretically it's possible if you encode an album as 1 stream and then split it without transcoding - but I'm unsure if there's a tool which can do that properly. (IIRC it's not so simple because in a middle of a stream an Opus packet requires a few previous packets to be decoded accurately)
The tiny glitches, not even always audible, between Opus tracks that do not use the latest encoder are not quite the same as not being gapless. Opus is inherently gapless and you'd have to go to special effort to put actual gaps between tracks. I'd expect the glitches to still be present in Android, but it also depends what you use for encoding/transcoding. See this thread (https://hydrogenaud.io/index.php?topic=116605.0) for some more details.
I've been using Opus on my Android for quite some time, even testing the Poweramp when they added support for it. Opus supports only track gain, and I didn't notice any problems with gapless playback. But when listening to whole albums, I turn off Replaygain because it's not needed. I use it only for self-made compilations.
Opus supports track or album replaygain, but it uses a confusing mish-mash if non-standard (well, standard, but only in Opus!) techniques so support is inconsistent across different tools. Depending on your encoder, you can force album replaygain and also have tag-based track replaygain that almost any decoder will respect, but equally you might not want to do it that way. What player are you using on Android? Have you experimented with the Opus replaygain tags in your Android player?
Haven't heard anything about fixing gapless encoding in Opus.
Theoretically it's possible if you encode an album as 1 stream and then split it without transcoding - but I'm unsure if there's a tool which can do that properly. (IIRC it's not so simple because in a middle of a stream an Opus packet requires a few previous packets to be decoded accurately)
The tiny glitches, not even always audible, between Opus tracks that do not use the latest encoder are not quite the same as not being gapless. Opus is inherently gapless and you'd have to go to special effort to put actual gaps between tracks. I'd expect the glitches to still be present in Android, but it also depends what you use for encoding/transcoding. See this thread (https://hydrogenaud.io/index.php?topic=116605.0) for some more details.
So there shouldn't be a problem if I batch convert the whole gapless albums with the latest opusenc? That's what I do anyway, I batch convert the FLAC music folders.
lvqcl developer mentions in that topic: "If your input files are 44.1 kHz: try to resample to 48kHz before encoding". opusenc resamples to 48 kHz before encoding.
You'd have to be paranoid
Haven't heard anything about fixing gapless encoding in Opus.
Theoretically it's possible if you encode an album as 1 stream and then split it without transcoding - but I'm unsure if there's a tool which can do that properly. (IIRC it's not so simple because in a middle of a stream an Opus packet requires a few previous packets to be decoded accurately)
The tiny glitches, not even always audible, between Opus tracks that do not use the latest encoder are not quite the same as not being gapless. Opus is inherently gapless and you'd have to go to special effort to put actual gaps between tracks. I'd expect the glitches to still be present in Android, but it also depends what you use for encoding/transcoding. See this thread (https://hydrogenaud.io/index.php?topic=116605.0) for some more details.
So there shouldn't be a problem if I batch convert the whole gapless albums with the latest opusenc? That's what I do anyway, I batch convert the FLAC music folders.
lvqcl developer mentions in that topic: "If your input files are 44.1 kHz: try to resample to 48kHz before encoding". opusenc resamples to 48 kHz before encoding.
I don't think that was a general recommendation. Opus will resample to 48 kHz (possibly less if you choose a ridiculous bitrate) but there isn't generally anything to be gained by doing it yourself.
Why not convert an album or two and see what you think. I don't think you'll have a problem with the gapless playback. Any glitches are extremely minor which is why it took so long to work out what the OP was hearing on the other thread. I'm less confident about the replaygain, but it should be possible to get it to do what you want even if it takes a bit of experimentation.
Okay so I tested myself. Grabbed 'Daft Punk - Alive 2007' which is a single live concert recording cut into gapless tracks. Resample FLAC to 48 kHz. Cut the ending of one track, the beginning of the next, and save those two as separate files (A.flac, B.flac). Then I save the two sticked together as a single file (A+B.flac). Ran them all through opusenc libopus 1.3.1.
AIMP latest (v4.60 build 2180), cross-mixing turned off, auto jump to next track.
First Playlist:
1.- A.opus
2.- B.opus.
Recording audio output on Audacity.
Second Playlist:
1.- A+B.opus.
Recording audio output on Audacity.
(https://i.ibb.co/Chv6PcB/soundwaves.png)
The two recordings are almost identical. Not exactly the same, they don't cancel out when inverting the soundwave, but not a single sample is misaligned. Also I don't hear anything unusual. I don't think I can ABX this. It looks and sounds the same.
Next is ReplayGain. Grabbed 'Daft Punk - Tron: Legacy'. Resample FLAC to 48 kHz. No ReplayGain tags.
Opus encode: opusenc --bitrate 160 in.flac out.opus
Vorbis encode: oggenc2 -q 6 in.flac
Run them through foobar2000 latest (v1.5.4) ReplayGain scan. Apply ReplayGain tags.
Track 3 - The Son of Flynn:
FLAC Track Gain -1.71 dB
FLAC Album Gain -4.93 dB
Opus Track Gain -1.71 dB
Opus Album Gain -4.93 dB
Vorbis Track Gain -1.69 dB
Vorbis Album Gain -4.89 dB
Play them on AIMP.
'ReplayGain normalization', 'Use value from tags', 'Souce: File'.
Afterwards, I try 'Source: Album'.
They sound the same. I don't hear any difference.
(https://i.ibb.co/tc46Bmt/aimp.png)
What's more, on that AIMP window, If I change the ReplayGain values of either Track or Album to -20 dB on FLAC / Opus / Vorbis files, I hear all files equally low.
So I don't know how Opus / foobar2000 / AIMP achieve this, but it works. Mp3tag shows Opus files have no ReplayGain tags, only R128 tags. R128_ALBUM_GAIN tag is 0. And it plays just it fine.
The codec delivers.
On cellphone I use AIMP too, hopefully works there as well.
Opus supports track or album replaygain, but it uses a confusing mish-mash if non-standard (well, standard, but only in Opus!) techniques so support is inconsistent across different tools. Depending on your encoder, you can force album replaygain and also have tag-based track replaygain that almost any decoder will respect, but equally you might not want to do it that way. What player are you using on Android? Have you experimented with the Opus replaygain tags in your Android player?
I am sorry, I was wrong. Opus does, indeed, supports Track and Album Gain tags, it just doesn't calculate and store peaks, because, as I understood the reasoning, being a lossy encoder with a lot of processing, those peaks during decoding can go 'up to 11', so to speak :) and it may lead to the wrong conclusion for the less techy people.
I am using PowerAmp on Android, paid version, and was using Opus files, listening albums without replaygain tags, and if I compiled something by myself, using just track gain. No problems whatsoever, working as expected.
I have tested Opus 1.3.1 (encoded via ffmpeg) against the number of gapless-encoding test files floating around on Cmus (Linux) and Mobile Foobar app on iOS. Both players support gapless.
Opus 1.3.1 encodings were NOT gapless. There were glitches, etc.
Yet, Vorbis encodings of the same files were gapless.
I did the tests as the the reports were inconclusive about this and I was mad enough to consider Opus again. But, again, I cannot escape from the thought that the devs might have moved onto something more interesting and we have now another not so perfect standard.
The fact of the matter that we want to tag each track separately. That calls for separate files. Gapless playback is absolutely essential for me not to feel myself in the 90-s. We are in the age of self-driving cars and all that nonsense, and even a new all singing all dancing format cannot support gapless.
I will stay with Vorbis, but then and there they totally ignored Aotuv's efforts, so one cannot even use standard builds.
Vorbis is perfect. It is gapless. It has a simple, but very versatile tagging system. It has pretty decent tuning. And it is supported everywhere.
...
What's more, on that AIMP window, If I change the ReplayGain values of either Track or Album to -20 dB on FLAC / Opus / Vorbis files, I hear all files equally low.
So I don't know how Opus / foobar2000 / AIMP achieve this, but it works. Mp3tag shows Opus files have no ReplayGain tags, only R128 tags. R128_ALBUM_GAIN tag is 0. And it plays just it fine.
The codec delivers.
On cellphone I use AIMP too, hopefully works there as well.
Like I said, Opus has a weird way of doing replaygain. The "correct" Opus way does not use the replaygain tags that are standard in every other codec. It defines its own R128_TRACK_GAIN and R128_ALBUM_GAIN tags. Furthermore, it has a field in the track header (called output_gain) which is also a gain tag. Early versions of the standard did not include the R128_ALBUM_GAIN tag and instead suggested that any album gain could be placed in the output_gain field. Since every decoder should apply this gain without even stopping to think about it, it is a fairly reliable way of making sure every player uses it. In fact it will be difficult to play a track *without* the output_gain applied, you might want to try that and see what happens. The actual track replaygain is the output_gain plus the R128_TRACK_GAIN. Having an R128_ALBUM_GAIN tag of zero was an intermediate solution supposed to indicate that the output_gain contained an album gain, since it could in theory contain anything for any reason (although nobody ever came up with anything sensible that it should contain, other than loudness normalisation).
Like I said, Opus has a weird way of doing replaygain. The "correct" Opus way does not use the replaygain tags that are standard in every other codec. It defines its own R128_TRACK_GAIN and R128_ALBUM_GAIN tags. Furthermore, it has a field in the track header (called output_gain) which is also a gain tag. Early versions of the standard did not include the R128_ALBUM_GAIN tag and instead suggested that any album gain could be placed in the output_gain field. Since every decoder should apply this gain without even stopping to think about it, it is a fairly reliable way of making sure every player uses it. In fact it will be difficult to play a track *without* the output_gain applied, you might want to try that and see what happens. The actual track replaygain is the output_gain plus the R128_TRACK_GAIN. Having an R128_ALBUM_GAIN tag of zero was an intermediate solution supposed to indicate that the output_gain contained an album gain, since it could in theory contain anything for any reason (although nobody ever came up with anything sensible that it should contain, other than loudness normalisation).
I've tested the files on the android cellphone. Android AIMP doesn't play gapless in any format.
Latest android foobar2000 works flawlessly with Opus. Track ReplayGain, Album ReplayGain, disabled ReplayGain, are applied just the same with FLAC or Vorbis or Opus. There are no gaps in between songs either. Not that I can hear.
The ReplayGain design you describe looks kind of quirky but if it works, it works.
I'm pretty satisfied, there's no reason for me to continue to use Vorbis. Ahoy! :)
I have tested Opus 1.3.1 (encoded via ffmpeg) against the number of gapless-encoding test files floating around on Cmus (Linux) and Mobile Foobar app on iOS. Both players support gapless.
Opus 1.3.1 encodings were NOT gapless. There were glitches, etc.
Yet, Vorbis encodings of the same files were gapless.
I did the tests as the the reports were inconclusive about this and I was mad enough to consider Opus again. But, again, I cannot escape from the thought that the devs might have moved onto something more interesting and we have now another not so perfect standard.
The fact of the matter that we want to tag each track separately. That calls for separate files. Gapless playback is absolutely essential for me not to feel myself in the 90-s. We are in the age of self-driving cars and all that nonsense, and even a new all singing all dancing format cannot support gapless.
I will stay with Vorbis, but then and there they totally ignored Aotuv's efforts, so one cannot even use standard builds.
Could you tell me where those lossless files are? I wanna test them to see where the problem lies.
For reference:
https://hydrogenaud.io/index.php?topic=48231.msg430069#msg430069 and
https://hydrogenaud.io/index.php?topic=40995.msg716135#msg716135
refers to the one I prefer. I prefer it as it is long and consists of 17 fragments.
https://web.archive.org/web/20070307021416/http://guruboolez.free.fr/samples/gapless/gapless_WAVPACK_free_of_right.zip
where you can download it. (I would rather not upload it ableit it is stated to be free of copyright.)
Actually,...
I did test with the samples I provided, and Cmus played them gapless on Vorbis, but not on Opus. This is certain.
However, I might not have put the Opus files on my iPhone to test it with Foobar as Linux gapless is equally important for me. Honestly I do not remember now. Let me know what you find.
Is there any Linux player that plays Opus gapless?
Anything that uses libopusfile should handle them gaplessly as they were encoded. Vorbis is handled gaplessly already because its decoder library handles that transparently, while the original libopus decoder required the application to implement that separately. libopusfile also came out a significant amount of time after the basic format and libopus were published, so many implementations didn't wait, and some didn't get the implementation details correct.
foobar2000 is one of the correct implementations based on libopus.
I can't really vouch for the only two Linux players I use beside foobar2000 in wine: Audacious, which is quite a lot like Winamp, even in its plugin design, and DeaDBeeF, which is a tad bit like foobar2000, but doesn't even do gapless MPEG-4 AAC in any form.
@kode54 Thx for the colour. I was poking around about this, and I could not find any such sane write-up about the situation.
I wish this would be communicated by the Opus team to the various app devs. If nothing else, just sticking it somewhere prominent in the Opus homepage.
I thought you were referring to this issue (https://hydrogenaud.io/index.php?topic=116605.0) with the gapless talk. As far as I know there is no existing solution for this problem.
I thought you were referring to this issue (https://hydrogenaud.io/index.php?topic=116605.0) with the gapless talk. As far as I know there is no existing solution for this problem.
wrong link? (points to this same thread)
DeaDBeeF use libopusfile. I've not noticed any gapless issues on Linux, but I haven't used it on Android.
I thought you were referring to this issue (https://hydrogenaud.io/index.php?topic=116605.0) with the gapless talk. As far as I know there is no existing solution for this problem.
I really could not hear any difference between those two *.wav source files and the two *.opus files. Listened on foobar2000 / AIMP PC. Audacity shows nothing strange either. If there's something going on, I don't notice it.
Since AIMP Android doesn't inherently play gapless with anything, I've gone the easy way out with it and encoded whole gapless albums on a single file bookmarked by a CUE. It does have gapless CUE playback.
this thread has gone me thinking, does anyone have any comparisons of how ReplayGain compares to Apple's SoundCheck ?
This thing is very confusing. The link Case quoted talks about libopusenc encoded files being perfect and the rest are just best efforts. Yet, I gathered even that one have issues?
At the same time, I have tested mpv last night with ffmpeg encoded files (linking libopus 1.3.1), and gaps were unnoticable. mpv does not use libopusfile. Probably they do some hack. I will do a few more tests. could settle on mpv as a player on my PC.
This whole thing is very confusing. I try to consider Opus, but I wonder if I could just stay on Vorbis.
This thing is very confusing.
Well yes. I can't hear / see any opus gapless glitch on either PC or Android. And yet there's someone on that topic actually ABXing the "glitch".
To me the glitch he describes is like he's talking about the typical audio glitch you get when changing sample rate mid-stream. Or playing non-faded in/out audio when going from complete silence to high amplitude sample
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?
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.
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.
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
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.
@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?
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
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
Best to stick to lossless rips, then. And stuff maybe MP3 or Vorbis on your mobile device.
@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.
The padding method of attempting to fix gaplessness probably won't work so well with Opus, due to its low latency design.
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 (https://hydrogenaud.io/index.php/topic,116605.msg963796.html#msg963796)
Encoded with latest libopus --bitrate 160
@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.
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?