So i have a bunch of regular 44100 flac files that i'de like to convert to OPUS file so i have something to listen to when i run, that's not very hard to setup following this guide.
http://www.saunalahti.fi/~cse/Opus/ (http://www.saunalahti.fi/~cse/Opus/)
What does concern me is that opusenc.exe seems to default to a samplingrate of 48000 when you feed it a raw stream (the '-' option as seen in the guide seems to do that) it's easy to see that the .opus files do indeed become converted/upsampled to 48000hz using this method.
So my question is, should i override this behavior by adding --raw-rate 44100 to the encoder?
Does it matter at all that the files get upsampled? Could it introduce noise or other unwanted side effects?
Thanks
(yes i know that there aren't many android players yet avail for playback of opus, but the question still remains)
Also i think this post belongs to this forums, at least it seemed like it was a good fit, but if i'm wrong please move it :\
Opus does not natively support 44Khz. The idea is that since 48Khz can store a 44Khz signal, this simplifies the algorithm. Then, it just stores the original format and size so that a decoder could decode to the same values, but a decoder is allowed to decode at another samplerate.
You might need the --raw-rate 44100 switch to tell it that the input is working at 44Khz so that it resamples.
Else, I believe it might be encoding directly as if it was a 48Khz signal, so playback would sound wrong (Haven't tried and I don't know how the commandline encoder works in this specific case).
You might opt to resample directly in the program feeding the stream (like foobar2000), or let opus resample. I don't know about the internal resampler's quality, but I know it's not bad.
So my question is, should i override this behavior by adding --raw-rate 44100 to the encoder?
If it is a raw PCM stream then it doesn't contain any header information. So the encoder won't know what is working with and you have to supply the correct values with the raw switches.
If it isn't raw like a WAV file then you do not use any of those options, because the sampling rate is already known from the header.
Every non-48Khz input rate will internally be converted to 48Khz. So the output will always be at 48Khz.
If you don't trust the internal resampler then you could always go and use something like sox.
that's not very hard to setup following this guide.
http://www.saunalahti.fi/~cse/Opus/ (http://www.saunalahti.fi/~cse/Opus/)
This guide is somewhat obsolete, you don't need to set up a custom encoder profile for Opus anymore.
What does concern me is that opusenc.exe seems to default to a samplingrate of 48000 when you feed it a raw stream (the '-' option as seen in the guide seems to do that) it's easy to see that the .opus files do indeed become converted/upsampled to 48000hz using this method.
So my question is, should i override this behavior by adding --raw-rate 44100 to the encoder?
Opus does not support sample rates of 44.1kHz, so setting the
input sample rate does not change the fact that the stream has to be resampled to 48kHz.
Does it matter at all that the files get upsampled? Could it introduce noise or other unwanted side effects?
Highly unlikely, though you can use any other foobar2000 DSP resampler to resample to 48kHz before conversion.
when you feed it a raw stream (the '-' option as seen in the guide seems to do that)
No it doesn't. foobar2000 doesn't send just raw data to encoders. And Opus encoder does know the samplerate of an input file.
how does the internal resampling effect gapless playback (and does opus even store enough metadata to allow for gapless playback)?
how does the internal resampling effect gapless playback (and does opus even store enough metadata to allow for gapless playback)?
Opus is intrinsically gapless.
how does the internal resampling effect gapless playback (and does opus even store enough metadata to allow for gapless playback)?
Opus is intrinsically gapless.
Does the internal resampler add any padding at the beginning or the end of the stream, then? Some resampling implementations will do this because they don't compensate for the group delay or because they let the filter decay out at the end.
Opus is intrinsically gapless.
It still produces a click/glitch with some problematic samples (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=81991&view=findpost&p=716229).
(So does every other lossy codec I tried, except for Vorbis.)
Apparently I might be wrong, it was deeply rooted at the back of my brain though, but I cannot find any reference through google right now. Though my usual test samples showed no problems at all, but that hardly proves anything.
So i have a bunch of regular 44100 flac files that i'de like to convert to OPUS file so i have something to listen to when i run, that's not very hard to setup following this guide.
http://www.saunalahti.fi/~cse/Opus/ (http://www.saunalahti.fi/~cse/Opus/)
Not want to steal the fun to create a new encoder option but the new version of foobar2000 has Opus already in its settings
I believe I read in another thread that opus can't truly do gapless, though it can get pretty close to it.
I think I've settled on continuing to use Vorbis for my lossy file encodes because it's the best lossy codec I've found for handling gapless, and gapless matters to me.
I want to see Opus succeed in the interactive space and streaming. If I was currently working on software or a project that involved either I would use Opus, hands down.
To the OP's question, the resampler in Opus is very good and will be transparent and time-aligned by the time it's decoded (its delay is specified by the encoder as part of the pre-skip delay and stripped out by the decoder), so you need not worry. In a lossless encoder, perceptual transparency is all that matters.
Also regarding gaplessness, all CD-sourced material is an integer number of CD frames in length, each lasting 1/75th of a second. Fortunately this is an integer number of samples at both 48000 Hz (640 samples) and 44100 Hz (588 samples) so the accurate length can be precisely specified at either sampling rate, so it works in Opus regardless.
An important addition to gapless playback for some sources is glitchless playback. Inherently, image+CUE files are glitchless but it seems nearly everyone desires track-per-file, few players support CUEsheets and many mainstream rippers are both insecure and don't support image+CUE.
Glitchless means that there should be no discontinuities in important aspects of the audio that could be perceived as a sound not present in the original music. Typically there might be level discontinuities that result in a broad band pop or click, or there might be slope discontinuities for example, with similar effect.
Glitchlessness appears, from posts above, to be acceptable in Ogg Vorbis with a suitably gapless player. It's also no problem in MP3s encoded as an image plus CUE then split into tracks with pcutmp3 (which uses the LAME accurate length and offset to create sample-accurate cuts and uses MP3 frames each side of the cut point in both halves of the split to maintain continuity, but only works with a player that supports LAME's gapless fix of course)
Opus uses asymptotically convergent prediction and specifies that a pre-skip is included in the header (http://wiki.xiph.org/OggOpus#Granule_Position), which is non-audio that must be decoded silently before the decoder produces any sound in order to sufficiently converge the predictors. This should be at least 80ms, and ideally a bit longer to eliminate glitches in the worst cases. In the case of individual tracks it's likely that an encoder will use silence, or potentially even try something 'clever' like the start of the track played backwards to train the predictors before the audio begins. As the header includes the pre-skip offset before audio should commence, it's entirely possible to feed the encoder with enough of the tail end of the previous track, to make it effectively glitchless.
I'd expect there's a bit of inertia to overcome to rewrite ripping software to actually provide the prior-track samples and offset to the start of desired track to the encoder in some way.
Perhaps the easiest way to implement glitchless Opus ripping is for the encoder to support Image+CUE input but to be told to output in file-per-track mode, whereby it can automatically pick the right amount of pre-roll and automatically include data from the end of the previous track. People who care about glitchless, gapless playback would be happy to use a ripper in Image+CUE mode, passing that to the Opus encoder. Otherwise or additionally, it will be necessary to implement a method to pass prior track audio samples plus the offset to the start of audio, or to specify a switch that requires a fixed amount of additional audio (e.g. 15 CD frames = 15/75s = 0.2 s) offset which the encoder will use to train the predictors in the decoder to match very closely what they would have been if the two tracks had been encoded as a single piece of audio.
About 0.2 s of unheard audio in a typical 180 second track will not appreciably increase the effective bitrate over a collection of audio tracks.
Also regarding gaplessness, all CD-sourced material is an integer number of CD frames in length, each lasting 1/75th of a second. Fortunately this is an integer number of samples at both 48000 Hz (640 samples) and 44100 Hz (588 samples) so the accurate length can be precisely specified at either sampling rate, so it works in Opus regardless.
Gah. Opus gives sample accurate lengths for all sample rates <=48000. The (cool indeed) convenience of CD frames lengths isn't needed.
Glitchless means that there should be no discontinuities in important aspects of the audio that could be perceived as a sound not present in the original music. Typically there might be level discontinuities that result in a broad band pop or click, or there might be slope discontinuities for example, with similar effect.
Opusenc should achieve that already on inputs that are themselves glitchless, so long as the bitrate is high enough for the first and last frames that the distortion from lossyness doesn't break it.
Glitchlessness appears, from posts above, to be acceptable in Ogg Vorbis with a suitably gapless player.
And opus is in the same boat as Vorbis WRT this.
Opus uses asymptotically convergent prediction and specifies that a pre-skip is included in the header (http://wiki.xiph.org/OggOpus#Granule_Position), which is non-audio that must be decoded silently before the decoder produces any sound in order to sufficiently converge the predictors. This should be at least 80ms, and ideally a bit longer to eliminate glitches in the worst cases. In the case of individual tracks it's likely that an encoder will use silence, or potentially even try something 'clever' like the start of the track played backwards to train the predictors before the audio begins.
No, a newly initialized encoder and decoder are instantly converged by definition. The 80ms advice applies to seeking. The preskip exists for three main reasons: To allow that convergence in streams that have been captured out of a longer running stream (analogous to seeking), to allow sample accurate trimming of existing encodes (same as the last reason, but different use case), and to hide the non-constant encoder+decoder latency (the decoder is constant, encoder depends on how its setup) to give sample accurate lengths.
I'd expect there's a bit of inertia to overcome to rewrite ripping software to actually provide the prior-track samples and offset to the start of desired track to the encoder in some way.
The original data may help improve the quality of the first and last frame. But I've not yet found an example where the existing LPC extrapolation (what vorbis does) for 'margin' filling is inadequate. Right now opusenc only LPC extrapolates the end, not the beginning, and it really surprises me that this is enough but so far it has been.
Thanks again for the corrections, NullC. You know your stuff. I'll rein myself in! I guess that means that if anyone has opus (or Vorbis) files that don't playback gaplessly and glitchlessly, they should provide examples with ABX logs against the join in the lossless originals.
The sample-accurate lengths for CD-sourced material resampled to 48kHz does mean however that it doesn't matter in the slightest whether the decoder plays back at 48kHz or resamples back to the original 44.1 kHz - it's still precise.
I guess that means that if anyone has opus (or Vorbis) files that don't playback gaplessly and glitchlessly, they should provide examples with ABX logs against the join in the lossless originals.
I linked to an example a few posts above. You should easily hear a glitch with the transition from m1 to m2 when encoded to Opus (or MP3/AAC). Well, it helps if you listen with headphones and raise the volume.
I also posted about this (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=803699) same problem in the other Opus thread and I uploaded the recordings of the transition. There was an Opus build that reduced the loudness of the glitch, but it didn't eliminate it.
I haven't heard much from others, but I'd be very surprised if I'm the only one who can hear this.
EDIT2: The only time I don't get a glitch is when I decode the opus files to
44.1k wav and then play them in foobar.
EDIT2: The only time I don't get a glitch is when I decode the opus files to 44.1k wav and then play them in foobar.
If you can't reproduce the problem with opusdec + opusenc then it may be something about foobar2000's behavior.
I can reproduce with opusenc+opusdec. In fact opusdec by default gives me 44.1k files which don't glitch in Foobar. But if I force --rate 48000 I get the glitch again.
I also tried to unite the WAV files from opusdec with Wavosaur and I get the glitch with both 44.1k and 48k, which is a bit confusing (it means Wavosaur and Foobar are not consistent with how they handle the 44.1k files in this case).
EDIT: tried with two other audio editors and they behave like Foobar: no glitch with 44.1k files, glitch with 48k ones (Audacity makes the glitch very obvious, for example)
EDIT2: correction: there's a glitch with 44.1k as well, it's just much quieter. But anyway, 48k is the important one, since it's Opus' 'native' SR.
In a lossless encoder, perceptual transparency is all that matters.
You meant to say lossy encoder. In a lossless encoder, bit accuracy is all that matters.
I'm usually very sensitive to glitches, but I don't seem to hear the glitch in "new build small glitch.wav". It's very audible in "older build louder glitch.wav". Images from Audition's Spectral Frequency Display: old (http://i.imgur.com/Jfpri.jpg), new (http://i.imgur.com/WAWYn.jpg).
Hehe. Gurkburk, du kan inte vara något annat än svensk med det smeknamnet. Translation (http://translate.google.com/#sv/en/Hehe.%20Gurkburk%2C%20du%20kan%20inte%20vara%20n%C3%A5got%20annat%20%C3%A4n%20svensk%20med%20det%20smeknamnet).
I have a similar question as the OP. In my case the input file is at 32 kHz sampling rate, and I want this to be encoded at high rates (i.e. CELT-only). Now there are two ways I can do this:
- Encode the 32-kHz file as-is. This gives me a file decoded at 32 kHz, or decoded at 48 kHz if I specify "--rate 48000" in the decoder command-line.
- Upsample the input to 48 kHz externally, then encode it. This gives me a 48-kHz output file which contains some artificial content between 16 and 20 kHz.
Which of the two approaches is more efficient? Intuitively I would choose the first approach, since that one only encodes content actually present in the input, but maybe CELT is more efficient on 48-kHz than on 32-kHz input (and the 16-20-kHz spectral range consumes almost no bits)?
What do the experts say?
Chris
I'm not an "expert" but from what I can see from opusenc.c (and audio-in.c) of opus-tools, it resamples 32kHz input to 48kHz (by speex resampler) before sending to encoder.
if(rate>24000)coding_rate=48000;
else if(rate>16000)coding_rate=24000;
else if(rate>12000)coding_rate=16000;
else if(rate>8000)coding_rate=12000;
else coding_rate=8000;
if(rate!=coding_rate)setup_resample(&inopt,coding_rate==48000?(complexity+1)/2:5,coding_rate);
st=opus_multistream_encoder_create(coding_rate, chan, header.nb_streams, header.nb_coupled,
mapping, frame_size<480/(48000/coding_rate)?OPUS_APPLICATION_RESTRICTED_LOWDELAY:OPUS_APPLICATION_AUDIO, &ret);
It might have not been enough explanation...
"rate" in the first part is the actual input sampling frequency, and it's get resampled to "coding_rate".
Yes, I expected Opus to resample to 48 kHz internally. The question was more: if it does, will the CELT coder know that the input was upsampled from 32 kHz by the Speex resampler, and limit its encoding bandwidth to 16 kHz (the bandwidth of the original input file), or is the 20-kHz bandwidth of high-bitrate CELT hard-coded regardless of the input sampling rate?
Chris
Yes, I expected Opus to resample to 48 kHz internally. The question was more: if it does, will the CELT coder know that the input was upsampled from 32 kHz by the Speex resampler, and limit its encoding bandwidth to 16 kHz (the bandwidth of the original input file), or is the 20-kHz bandwidth of high-bitrate CELT hard-coded regardless of the input sampling rate?
Input sample rate doesn't seem to be get passed to the encoder (although it is used in the calculation of default bitrate, when user doesn't provide it via --bitrate).
Yes, I expected Opus to resample to 48 kHz internally. The question was more: if it does, will the CELT coder know that the input was upsampled from 32 kHz by the Speex resampler, and limit its encoding bandwidth to 16 kHz (the bandwidth of the original input file), or is the 20-kHz bandwidth of high-bitrate CELT hard-coded regardless of the input sampling rate?
Opus doesn't actually have a mode for 16 kHz bandwidth (only 12 and 20). However, the new 1.1-alpha release has new code (it may not be 100% reliable) to avoid wasting bits on frequencies that aren't present in the signal being coded.
Thanks, guys. I'll wait for the 1.1 beta then. Too scared of alphas.
Chris
Chris, feel free to submit problematic samples for 1.1a. Experienced ears are required.
Also I'm planning to organize unofficial test of Opus 1.1a vs stable here on HA.
Why 48kHz?
If the lowpass frequency is 20kHz (http://lists.xiph.org/pipermail/opus/2013-January/001939.html) why not resample everything to 40kHz instead of 48.
Or why not a higher lowpass setting at higher bitrates? I doubt that 20kHz is a hard limit to everyone anyway. Some might hear a few kHz higher if its loud enough
why not resample everything to 40kHz instead of 48.
A more complete list of
common audio sample rates is: (http://en.wikipedia.org/wiki/Sampling_rate#Audio) ...
Doesn't the CELT layer work strictly at 48 kHz regardless of input sample rate?
I think the CELT layer in Opus (possibly not in the old CELT codec) works also at 24kHz sampling rate (12kHz bandwidth) - and this is used at least for the 8-12kHz part of the spectrum in the hybrid mode.
I think the CELT layer in Opus (possibly not in the old CELT codec) works also at 24kHz sampling rate (12kHz bandwidth) - and this is used at least for the 8-12kHz part of the spectrum in the hybrid mode.
No that is incorrect. In Opus, the CELT layer *always* works at 48 kHz, even if it's only coding a small part of the spectrum.
Something is still not clear to me: is the internal resampler always used even if the input is 48 kHz already ?
No, a resampler changes the sampling rate. If the rate is already correct there is nothing to change.
That's the theory, but does it *really* behaves that way in the OPUS encoder builds provided by the Xiph staff ?
That's the theory, but does it *really* behaves that way in the OPUS encoder builds provided by the Xiph staff ?
Yes. Its nonsensical to operate any other way.
That's the theory, but does it *really* behaves that way in the OPUS encoder builds provided by the Xiph staff ?
Do you have any credible evidence causing you to believe otherwise?
Thats the problem with these totally opaque closed source programs, it's completely impossible to tell what they really do... you can only speculate about it on forums.
Thats the problem with these totally opaque closed source programs, it's completely impossible to tell what they really do... you can only speculate about it on forums.
That's only true for so called "cloud" programs.
Thats the problem with these totally opaque closed source programs, it's completely impossible to tell what they really do... you can only speculate about it on forums.
I forgot to react the first time around: what are you talking about? Opus is open source software. Or was it sarcasm?
Yes, I think we can safely deduce that sarcasm was at work. The point, thinly veiled, was that Brazil2 could answer his/her own questions by checking the freely available source code. Whilst I agree to some degree, I acknowledge that we could have a debate about whether non-programmers should be expected to analyse code, but I would prefer that we avoid such divergence.
Banned, I presume your insinuation is that, even for closed-source programs, as long as they are stored locally, one could technically manage to disassemble them and work out what they are doing. In that case, how prepared do you think the majority of users are to do such a thing? If something is closed-source, it might as well be impenetrable to analysis, in a practical sense. But Opus is not, so the point is irrelevant in any case.
Anyway, given that NullC did not say otherwise, and that the programmers of Opus are obviously more than competent, I presume the aforementioned logical assumption—that it does not resample when doing so would be pointless—is correct.
For listening test (wav file).
If I resample to 44.1 kHz with SoX (http://sox.sourceforge.net/Main/HomePage) (sox any-file outfile rate 44100) is this audible?
You tell us. You even mentioned listening tests. Questions like this are precisely why they exist.
You tell us. You even mentioned listening tests. Questions like this are precisely why they exist.
When somebody listening wav files (same song) and one wav has 48000 Hz sample rate then predictable that was opus.
An assumed condition of double-blind tests is that the subject knows absolutely nothing about any of the samples. What’s your point, exactly?
For listening test (wav file).
If I resample to 44.1 kHz with SoX (http://sox.sourceforge.net/Main/HomePage) (sox any-file outfile rate 44100) is this audible?
If you hear a difference between the resampled and original signals, it might be due to differences in your playback chain for the different rates. So to eliminate this possibility, resample back to the original rate before comparison.
You might conceivably hear a difference if your original signal is not band-limited (e.g. it's a dirac pulse, or 'click'), since the resampled signal will be band-limited, and how that band-limiting is done may be different between the resampler and the playback chain; this is not an issue for normal recorded audio (or carefully constructed test-signals) though.
Ok. Thx!
Here is my experience with Opus and handling of a different sample rates.
Opus has an internal resampler to convert input to 48 kHz. It has a high quality and nobody should be able to notice a difference.
Personally I use foobar's SoX resampler plugin (http://www.hydrogenaudio.org/forums/index.php?showtopic=67373) with the highest quality settings
Very High Quality mode (VHQ) is an overkill in terms of transparency and still pretty fast.
It yields some safeness when different sample rates are treated in tests of a lossy codecs.
Furthermore SoX resampler works in floating point 32 bits internally and today practically all lossy encoders support 24/32 bits input.
My encoding/decoding chain looks like :
Source PCM (44.1/16) -> foobar’s SoX (48/32 floating point) -> Opus (native 48 kHz) -> decoded to PCM (48/24 bits).
The last step can be "SoX 44.1/16 or 24" but since my soundcard, Essence STX, works better at 48 kHz I set everything (OS, foobar player, sound card settings etc.) to this sample rate.
Again, if my soundcard supports 24 bits playback I just prefer to stay on a safe side and resample everything to 48/24 even if a resampling to 48/16 is already transparent.