Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: IETF Opus codec now ready for testing (Read 393045 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #426
You should get plenty of battery life as your EVO has 28 nm CPU. Mine is 45 nm and battery last 15 hours and 33 minutes on rockbox. http://rasher.dk/rockbox/android/
http://www.hydrogenaudio.org/forums/index....st&p=809617

Even more at 64 kbps.


Thanks for the link to RockBox. Never tried it on here before, but I trust the maturity of the codebase (if not the interface) on mobile devices and ARM architecture more than VLC. It indeed plays the files with incredible ease, but the interface is non-existent (downloaded the 720x1280 but still, no controls visible and I had to guess where to tap -- eventually ended up playing, which is great). Comparison might not be as "fair" with VLC because RockBox doesn't work with Beats or Direct Volume Control like VLC seemed to. Also, VLC supports native ICS lockscreen and such, so right now it is probably the better player on the interface/app level.

I wonder what resampler (48KHz > 44.1KHz) VLC uses (linear for RockBox I believe). Either way, very promising news indeed!
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

 

IETF Opus codec now ready for testing

Reply #427
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.
keeping audio clear together - soundexpert.org

IETF Opus codec now ready for testing

Reply #428
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


You could probably just modify it to dump the raw floats then convert them to whatever precision you wanted.

IETF Opus codec now ready for testing

Reply #429
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


Opusdec definitely tries to return the original bit depth and sampling rate and duration so as not to surprise the user. Internally, it works with floating point (unless compiled for fixed point). Doesn't it return 24-bit if the encoder's input was 24-bit. I could see it using only 16-bit as 24-bit is pointless for a lossy encoder, and really for anything in a final consumer delivery format, as Monty's blog post at xiph.org explains in detail.

fb2k is geared to playback and uses floating point processing architecture, so doesn't as yet pass these original parameters to the Converter to allow automatic resampling and dithering to the original bit depth and sampling rate when decoding Opus.

I'd be astounded if fb2k decoded Opus then converted to 16-bit anywhere before the end of the entire processing chain. That's just not the fb2k design philosophy! Simple to check though if you turn off dither in the Converter dialogue and choose your bit depth or output floats. You could even edit the OpusGain field in the Opus stream with a hex editor to turn it down by 100 dB, decode to 24-bit/32-bit Float in fb2k then apply 100 dB of gain to confirm it's not throwing it away.
Dynamic – the artist formerly known as DickD

IETF Opus codec now ready for testing

Reply #430
Opusdec definitely tries to return the original bit depth and sampling rate and duration so as not to surprise the user. Internally, it works with floating point (unless compiled for fixed point). Doesn't it return 24-bit if the encoder's input was 24-bit. I could see it using only 16-bit as 24-bit is pointless for a lossy encoder, and really for anything in a final consumer delivery format, as Monty's blog post at xiph.org explains in detail.

For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.

I'd be astounded if fb2k decoded Opus then converted to 16-bit anywhere before the end of the entire processing chain. That's just not the fb2k design philosophy! Simple to check though if you turn off dither in the Converter dialogue and choose your bit depth or output floats. You could even edit the OpusGain field in the Opus stream with a hex editor to turn it down by 100 dB, decode to 24-bit/32-bit Float in fb2k then apply 100 dB of gain to confirm it's not throwing it away.

After your's and Peter's replies I'm pretty sure that Foobar can decode .opus with true 24bit accuracy. Your test suggestion is clever, not tried it yet though.
keeping audio clear together - soundexpert.org

IETF Opus codec now ready for testing

Reply #431
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

Albibeno Sample

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.

IETF Opus codec now ready for testing

Reply #432
For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.


Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48.

I'd imagine decoding to a PCM file is fairly rare use case compared to playback to the soundcard, and opusdec would in any case decode AND resample in floating point before switching to fixed-point PCM. The imperfections allowed by lossy encoding are usually far above 16-bit quantization noise.
You might then indirectly resample that PCM (with calculations carried out at 24 or 32-bit) if, for some reason, you chose to play it over your soundcard via e.g. Windows Mixer at 48kHz.

Any added noise is broad-spectrum, and only adds up to -90 to -95 dB over the entire bandwidth. The ear is more of a spectrum analyzer than an oscilloscope. Over the ear's typical discriminating bandwidth it is probably about 110-120 dB below a full-scale sinusoid at the same frequency and even with music mastered with 20 dB of headroom, that's over 90 dB per band. Considering a very quiet room is about 30 dB SPL, pretty loud music is 90 dB SPL and pain is about 120 dB SPL, that's plenty unless you start turning up the volume hugely during fade-outs.

Sure it's always good practice to process and edit at 24 bits or better to prevent significant accumulation of noise over many many multiple editing processes and echo and reverb, but for regular listening even with pretty heavy dynamic range compression, it should be overkill by quite a big margin.
Dynamic – the artist formerly known as DickD

IETF Opus codec now ready for testing

Reply #433
Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48.

I'd imagine decoding to a PCM file is fairly rare use case compared to playback to the soundcard, and opusdec would in any case decode AND resample in floating point before switching to fixed-point PCM. The imperfections allowed by lossy encoding are usually far above 16-bit quantization noise.
You might then indirectly resample that PCM (with calculations carried out at 24 or 32-bit) if, for some reason, you chose to play it over your soundcard via e.g. Windows Mixer at 48kHz.
Right, our recommendation is to only preserve the original rate for file output; for playback you playback at 48kHz preferably, whatever you can do otherwise (with resampling).

Opusdec does this.  And for the float->16 bit conversion it uses a proper noise shaping triangular dither with a conservative shaping filter that limits the HF noise boost.  Why bother? Why not. You can construct crazy cases where the intermod from straight truncated quantization is audible... and I don't know how loud the signal will be played back. It probably doesn't matter, but on desktops CPU time is free relative to how much work it takes.  (plus you can turn it off)

I'll gladly take a patch to add float output, I just couldn't be bothered to figure out the required wav magic, though the reader code for opusenc handles it.

IETF Opus codec now ready for testing

Reply #434
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.


I just checked and the latest code in master (just merged from exp_analysis branch) actually detects this as highly tonal and increase the bit-rate way up. This should be enough to fix the problem (please try it and let me know).

IETF Opus codec now ready for testing

Reply #435
For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.


Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48. ....................
Sure it's always good practice to process and edit at 24 bits or better to prevent significant accumulation of noise over many many multiple editing processes and echo and reverb, but for regular listening even with pretty heavy dynamic range compression, it should be overkill by quite a big margin.


24bit output is important not only because of resampling of course; consuming of audio becomes more and more sophisticated on listener's side today - at least using of some DSP is presupposed, not to say about mixing with other audio and frequent necessity to transcode to lower bitrates. From this perspective the use of 16bit audio and corresponding bit reduction techniques look supplementary while 24bit audio chain on consumer side looks quite natural and even more simple.
keeping audio clear together - soundexpert.org

IETF Opus codec now ready for testing

Reply #436
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.


I just checked and the latest code in master (just merged from exp_analysis branch) actually detects this as highly tonal and increase the bit-rate way up. This should be enough to fix the problem (please try it and let me know).


Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

IETF Opus codec now ready for testing

Reply #437
Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

My English is even worse, but he's saying that PSY tuning developed under exp_analysis7 branch was merged into main branch recently, therefore soon it will become "official".
(This merge was committed at Oct 9, so current official win32 binary (0.15) doesn't include this).
Code: [Select]
commit 7315b35e13a3a7c504ed6b1fe2d28ad500eb2701
Merge: ca82894 317ffc2
Author: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date:   Tue Oct 9 03:07:06 2012 -0400

    Merge branch 'exp_analysis7'

    Conflicts:
        celt/celt.c
        celt/mdct.c
        include/opus_defines.h
        src/opus_encoder.c

IETF Opus codec now ready for testing

Reply #438
Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

My English is even worse, but he's saying that PSY tuning developed under exp_analysis7 branch was merged into main branch recently, therefore soon it will become "official".
(This merge was committed at Oct 9, so current official win32 binary (0.15) doesn't include this).
Code: [Select]
commit 7315b35e13a3a7c504ed6b1fe2d28ad500eb2701
Merge: ca82894 317ffc2
Author: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date:   Tue Oct 9 03:07:06 2012 -0400

    Merge branch 'exp_analysis7'

    Conflicts:
        celt/celt.c
        celt/mdct.c
        include/opus_defines.h
        src/opus_encoder.c



Thanks for the explanation, I guessed it somehow but wasn't sure. Would be nice to have a compiled exe of this btw. Can someone upload it?

IETF Opus codec now ready for testing

Reply #439
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

IETF Opus codec now ready for testing

Reply #440
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?

Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608
Thank you very much!
I've tested the sample once again with the new version and could still ABX it at 192 kbps.

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14
2012/10/22 15:19:40

File A: C:\Dokumente und Einstellungen\Master O\Desktop\Albibeno (Sample).flac
File B: C:\Dokumente und Einstellungen\Master O\Desktop\Albibeno (Sample).opus

15:19:40 : Test started.
15:19:55 : 01/01  50.0%
15:20:49 : 02/02  25.0%
15:21:13 : 03/03  12.5%
15:21:34 : 04/04  6.3%
15:39:18 : 05/05  3.1%
15:39:38 : 06/06  1.6%
15:39:51 : 06/07  6.3%
15:41:11 : 07/08  3.5%
15:41:32 : 08/09  2.0%
15:42:38 : 08/10  5.5%
15:42:54 : 09/11  3.3%
15:43:21 : 10/12  1.9%
15:43:49 : 11/13  1.1%
15:45:11 : 12/14  0.6%
15:45:23 : Test finished.

 ----------
Total: 12/14 (0.6%)

I'm not sure if the result is of any worth though, as I used the Direct Sound output of Windows XP, which is known for its terrible resampler. The artifact I noticed is a slight distortion on the echo of the first two notes (right channel), which makes this sound a bit sharper. Maybe someone can verifiy it?

IETF Opus codec now ready for testing

Reply #441
You can try to set a native (the same as .opus file) sample rate to avoid possible resampling-related issues and/or resample the output with SoX with very high quality VHQ (which is transparent  ).

I would try to resample (44.1 kHz -> 48kHz) the original before encode to Opus with SoX VHQ resampler, just to see if it's not built-in Opus'es resampler.

IETF Opus codec now ready for testing

Reply #442
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.

IETF Opus codec now ready for testing

Reply #443
Quote
Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

Thanks for posting that. I saw there was a 'cygopus-0.dll' in the archive.

I quickly created a C# project to see if I can call any methods:

Code: [Select]
[DllImport("cygopus-0.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
public static extern string opus_get_version_string();


Once I called 'opus_get_version_string()' I received 'libopus 1.0.1'. Yay!

I think it would be nice if the next 'opus tools' release includes win32 dlls like this one. (Or a seperate download for the libopus dll)

IETF Opus codec now ready for testing

Reply #444
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.

Sorry, but you lost me with the "CELT frames" and "hitting the analysis" part, can you explain that a bit further? I've compared the new master with the recent exp versions yet btw, and they differ at the bitrates and RG peaks, so I guess there happened more than just minor bugfixing at the updates.

IETF Opus codec now ready for testing

Reply #445
After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.


Actually, the changes in exp_analysis7 (which are now in master) do affect 96 kb/s. If you're seeing bit-identical output, you're doing something wrong.

IETF Opus codec now ready for testing

Reply #446
After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.


Actually, the changes in exp_analysis7 (which are now in master) do affect 96 kb/s. If you're seeing bit-identical output, you're doing something wrong.

Not sure which, but I swear I ran the exact same conversions this morning as yesterday, and today the exp branch is hugely different on the same songs. (120kbps vs 97kbps on one track, 65 vs 94 on another.) Yesterday, only the library name and frame headers were different at all. I built it myself a few times and didn't change anything but the bitrates in FB's converter, even checked the process command lines in process explorer; but whatever, it is obviously doing something now.

IETF Opus codec now ready for testing

Reply #447
Poweramp gained OPUS support! Posted two days ago, "Opus is successfully added to current Poweramp dev builds, including opus in .opus and .ogg files, full gapless and replay gain support."

To commemorate the occasion, here is a CVS-master compile of opus-tools (use opusenc to encode), including dlls for libopus and libogg (1.3.0).

This is today's Opus as well as today's opus-tools, featuring the new experimental tweaks (the now-merged exp_analysis7 branch). It's also 3 times as fast as brat-h's cygwin compile above on my system (requires SSE).
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

IETF Opus codec now ready for testing

Reply #448
Poweramp gained OPUS support! Posted two days ago, "Opus is successfully added to current Poweramp dev builds, including opus in .opus and .ogg files, full gapless and replay gain support."

To commemorate the occasion, here is a CVS-master compile of opus-tools (use opusenc to encode), including dlls for libopus and libogg (1.3.0).

This is today's Opus as well as today's opus-tools, featuring the new experimental tweaks (the now-merged exp_analysis7 branch). It's also 3 times as fast as brat-h's cygwin compile above on my system (requires SSE).


Thx The Sheep of DEATH, it also encodes much faster than the official release (45x vs 30x for me).
Though I'm having a hard time deciding which is better quality... The bitrate varies quite a lot but I managed to compare a few at the same bitrate (can't disclose what I thought sounded better since my I don't have the time or patience to do a proper ABX).

IETF Opus codec now ready for testing

Reply #449
Thx The Sheep of DEATH, it also encodes much faster than the official release (45x vs 30x for me).
Though I'm having a hard time deciding which is better quality... The bitrate varies quite a lot but I managed to compare a few at the same bitrate (can't disclose what I thought sounded better since my I don't have the time or patience to do a proper ABX).


Glad to hear it! Besides much more drastic bitrate fluctuations, a definitive improvement in ringing is noticeable on one of my samples at (specified) 68kbps. The old version produced a file at 62kbps (with ringing on the vocals), while the new version produced a file that was over 74kbps (with ringing much reduced on the vocals). The instrumental version (w/o vocals) of the same song came out to be nearly identical in bitrate (62 old, 63 new).

Interesting.
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon