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 392722 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #375
Weird, does CVBR do the same?

I'll try this out later.

Did you use some low-pass with the C64 stuff? I know I tried some emulator once and it was producing way too much harmonics above 12kHz, it was practically unlistenable using monitoring headphones (unless you like your ears bleeding from the treble).

Haven't used lowpass. The source was a 44.1kHz Mono 16 bit WAV file.

Are you talking about a one-channel file or a two-channel file where both channels are the same. If it's the former, then the behaviour is probably normal considering that your C64 music is likely highly tonal.

Yes, it was a single channel WAV file. They are the tunes of the game: Creatures.

The SID synthesizer is rather simple, the spectrum of frequencies probably very distinct. Similar to the results for "Stranglehold".

Probably. But the bitrate is still much more higher than expected

IETF Opus codec now ready for testing

Reply #376
There is a new opus 1.0.1 RC3 release candidate up, as well as a 0.1.5 opus-tools at http://www.opus-codec.org/downloads/ .  These releases make minor build system changes and other small cleanups, other than some command-line options being changed a bit in opus-tools they are functionally identical to prior versions.

As always testing and trouble reports are appreciated.

Why "--music" option was removed?

Imho, the usage of the encoder should be like this:
> opusenc [options] input_file [output_file[.opus]]
If no output file is specified, it should become input_file_name.opus automatically. If no extension for output file is specified, it should become ".opus" automatically (except when there is a "." at the end of it).


IETF Opus codec now ready for testing

Reply #378
From http://wiki.xiph.org/OggOpus:
Quote
If a tool modifies the OpusHead "output gain" field, it MUST also update or remove the R128_TRACK_GAIN comment field.

There is no comment field corresponding to Replaygain's ALBUM_GAIN; that information should instead be stored in the OpusHead 'output gain' field.

To avoid confusion with multiple normalization schemes, an OpusTags packet SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK fields.


Good to see R128 as default.

I'm just wondering about the implications of this for people using OPUS as a music storage format (rather than streaming).

While I'm entirely happy to normalize all my music using Album Gain, I know there are people who are a bit 'precious' about preserving of being able to revert to the 'original loudness' of the tracks as if it were 'intended' by a mastering engineer with reference to a standard, which is barely ever the case, unlike with calibrated movie theatre audio.

Can the reversion gain be applied in an optional and unsupported comment tag field (which could eventually be used to modify the file to retroactively adjust the mandatory 'output gain' field, and also update or remove the R128_TRACK_GAIN comment field as it MUST), or would most encoders be likely (but not guaranteed) to produce the original loudness by treating the OpusHead 'output gain' field as if it were zero?
Dynamic – the artist formerly known as DickD

IETF Opus codec now ready for testing

Reply #379
Possibly interesting sidenote:

A "notorious" (politically interested) german blogger and podcaster, Fefe, discovered Opus as a) efficient codec for speech, to save bandwidth; b) flagship of freedom, using patent-free open-source code. So I'd expect the next releases of "Alternativlos" being offered in Opus as well. And that may just be a beginning...

IETF Opus codec now ready for testing

Reply #380
Chiptunes and similarly synthesized music seem to pose a problem for Opus. I've encountered a difficult sample for Opus 1.0.1 RC3: The beginning of the track "Flicker" by Big Giant Circles, which consists of two side-alternating NES-like synths.

Opus produces a distortion that is quite annoying up to VBR ~130 kbit/s and can be ABXed up to VBR ~200 kbit/s. The distortion is most noticeable in the first 5-6 seconds, after which an underlying pad sound begins to make distinction a little more difficult. I also did a test with VBR ~300 kbit/s but could not get conclusive ABX results.

I've uploaded the sample FLAC, the encoded Opus files and the ABX results for 130, 160 and 200 kbit/s VBR here so you can have a look (and a listen) at it. I don't have access to my FTP from the office, so Dropbox will have to do.

Download Sample ZIP
Nothing is impossible if you don't need to do it yourself.

IETF Opus codec now ready for testing

Reply #381
Chiptunes and similarly synthesized music seem to pose a problem for Opus. I've encountered a difficult sample for Opus 1.0.1 RC3: The beginning of the track "Flicker" by Big Giant Circles, which consists of two side-alternating NES-like synths.

Please be sure to also try the exp encoder higher up in the thread here.

Thanks for the report.

IETF Opus codec now ready for testing

Reply #382
Please be sure to also try the exp encoder higher up in the thread here.
I've tested the two exp encoders from #365 and got results similar to those of darkbyte's SID music: With both encoders, bitrates were way higher than with 1.0.1 RC3. Here's a crude table with the average bitrates of the three encoders for different encoding settings. T1 is g32024cb, T2 is gdc4f83b, in tune with #365.

Code: [Select]
Setting      1.0.1RC3 T1   T2

VBR 64          66    130  118
VBR 100        103    191  182
VBR 130        134    239  233
VBR 200        206    348  346
The sound quality was significantly higher for each setting, which did not surprise me that much anymore after looking at the bitrate. Still, VBR 130 (exp) was still ABX-able despite the high bitrate. I didn't try ABXing anything higher than that due to fatigue (tests were done around 1 am, it's 2:30 am now). Also, I could not find any audible differences between the two exp encoders at any of the tested quality settings.

Out of curiosity, I also did a matchup between 1.0.1RC3 and T1 at CVBR 64. Here T1 produces the same kind of distorted noise, but it is louder than with 1.0.1RC3.

Download audio and ABX results
Nothing is impossible if you don't need to do it yourself.

IETF Opus codec now ready for testing

Reply #383
I thought you guys might like to know that the PowerAMP for Android developers have confirmed that they're integrating the OPUS CODEC into the app soon:

Quote
Actually, we're looking into adding it. Most probably will be in the next intermediate build.
Thanks!


IETF Opus codec now ready for testing

Reply #384
Chiptunes and similarly synthesized music seem to pose a problem for Opus. I've encountered a difficult sample for Opus 1.0.1 RC3: The beginning of the track "Flicker" by Big Giant Circles, which consists of two side-alternating NES-like synths.

Opus produces a distortion that is quite annoying up to VBR ~130 kbit/s and can be ABXed up to VBR ~200 kbit/s. The distortion is most noticeable in the first 5-6 seconds, after which an underlying pad sound begins to make distinction a little more difficult. I also did a test with VBR ~300 kbit/s but could not get conclusive ABX results.

I've uploaded the sample FLAC, the encoded Opus files and the ABX results for 130, 160 and 200 kbit/s VBR here so you can have a look (and a listen) at it. I don't have access to my FTP from the office, so Dropbox will have to do.

Download Sample ZIP

I figured I'd add a datapoint: I've seen the exact same behavior with all other audio codecs. Vorbis, MP3, and AAC definitely all jump enormously with such synthetic triangle and square waves, and I can ABX their sound at much higher bitrates than even otherwise difficult samples like classical music. For instance, using vorbis at q2, ~96kbps, I get 140-160kbps for some complex SID songs. SID conversions (along with NSF and other pure synth music) should be considered torture samples and treated as such, although if a way to model them shows up I'll be greatly appreciative and gladly reconvert my entire library of old-school favorites.

IETF Opus codec now ready for testing

Reply #385
For the sample I've tested, the other lossy encoders don't show the same behaviour. I did a quick comparison at ~64 kbit settings, and while LAME V9 goes up to an average of 80 kbit/s, the other encoders (Quicktime AAC, Nero AAC, aoTuV Vorbis, Opus 1.0.1RC3) all stay around 64 kbit/s. Plus, the two AAC encoders produce less noise than the two Opus encoders which use roundabout the double amount of bits.

Of course I know this is difficult terrain for lossy codecs, where distortion and noise can quite easily be found amidst the clean synth waves. Nevertheless, at this point this seems to be not only problematic in comparison to other kinds of sound, but also in comparison to other encoders.
Nothing is impossible if you don't need to do it yourself.

 

IETF Opus codec now ready for testing

Reply #386
I've tested the two exp encoders from #365 and got results similar to those of darkbyte's SID music: With both encoders, bitrates were way higher than with 1.0.1 RC3.
This is because you're testing on a sample that is hard for Opus. This is the reasonable and expected behavior. On large diverse collections the EXP should give ~the same average rates... but on single tracks it can crank the rate.

I'm not sure what "VBR 130 (exp)"  means because you have datapoints where 130 was delivered and where it was requested.  ABXable for 66kbit/sec collection average (requested) is expected, hopefully it just doesn't sound bad.  ABXable for 130 collection-rate (requested) would be worth a closer look.

For the sample I've tested, the other lossy encoders don't show the same behaviour. I did a quick comparison at ~64 kbit settings, and while LAME V9 goes up to an average of 80 kbit/s, the other encoders (Quicktime AAC, Nero AAC, aoTuV Vorbis, Opus 1.0.1RC3) all stay around 64 kbit/s. Plus, the two AAC encoders produce less noise than the two Opus encoders which use roundabout the double amount of bits.
Of course I know this is difficult terrain for lossy codecs, where distortion and noise can quite easily be found amidst the clean synth waves. Nevertheless, at this point this seems to be not only problematic in comparison to other kinds of sound, but also in comparison to other encoders.

Opus is not MP3, AAC, or Vorbis. It is a _very_ different format and has different difficulty areas owing to the short (low latency) low-overlap transforms and the enormous vector quantization. Tonal samples without simple harmonic structure are a known and expected challenge area. On the other hand it handles noisy and high transient samples fairly well.

IETF Opus codec now ready for testing

Reply #387
I'm not sure what "VBR 130 (exp)"  means because you have datapoints where 130 was delivered and where it was requested.  ABXable for 66kbit/sec collection average (requested) is expected, hopefully it just doesn't sound bad.  ABXable for 130 collection-rate (requested) would be worth a closer look.


Ah yes, that might have been confusing. I meant VBR with requested 130 where exp encoders delivered 239 and 233 respectively.

ABXable for 130 collection-rate (requested) would be worth a closer look.


My ears can't pull that off. With the majority of my music, distinction is difficult or impossible for me at ~80 kbit/s. Good job!
Nothing is impossible if you don't need to do it yourself.

IETF Opus codec now ready for testing

Reply #388
Anybody knows what Opus Encoder setting gives "same" result as Ogg Vorbis at q6.0?

192kbps VBR maybe?

IETF Opus codec now ready for testing

Reply #389
Anybody knows what Opus Encoder setting gives "same" result as Ogg Vorbis at q6.0?


Given that these codecs differ a lot in what material is "difficult" for them and produce different artifacts, I would assume this is hard (impossible) to say, aside from transparent bitrates. However, I would also assume the jury is still out to determine what setting is transparent for Opus (and this will change as the encoder progresses).

IETF Opus codec now ready for testing

Reply #390
Ogg Vorbis -q 6 is transparent to me, so I assume that you want to achieve transparency. Only an ABX session can tell you that. I ran a few myself, and I couldn't ABX Opus at 128 kbps.

IETF Opus codec now ready for testing

Reply #391
Ok, thanks. I wan't to use it for my mobile music library.

IETF Opus codec now ready for testing

Reply #392
I'd prefer to wait with this attempt. There are still experimental encoders being tested (remember aoTuV mods for Vorbis?), and there is no reliable expectation about consumer player support yet...

IETF Opus codec now ready for testing

Reply #393
Ok, thanks! I've always used the original Ogg Vorbis Encoder ...

IETF Opus codec now ready for testing

Reply #394
I'm just wondering about the implications of this for people using OPUS as a music storage format (rather than streaming).

While I'm entirely happy to normalize all my music using Album Gain, I know there are people who are a bit 'precious' about preserving of being able to revert to the 'original loudness' of the tracks as if it were 'intended' by a mastering engineer with reference to a standard, which is barely ever the case, unlike with calibrated movie theatre audio.

There is another implication that I had first flagged as a foobar2000 bug before realizing it is a result of the gain tags in Opus.
Following the recommendations in the Ogg Mapping for Opus document, the following situations are indistinguishable for a decoder:
1. Track Gain = X; Album Gain = X
2. Track Gain = X; Album Gain is not set

Both situations result in an "output gain" value of X while R128_TRACK_GAIN is set to 0 or missing. At the moment, foobar2000 interprets it as "Track Gain = X; Album Gain = X". That means that for tracks that have been scanned for Track Gain only, it also reports an Album Gain value that is the same as the Track Gain value.

While that is no problem for playback, it wreaks havoc with my (and possibly other people's) playlist grouping scheme. Of course I don't know the format very well, but in my opinion the introduction of a field like "R128_ALBUM_GAIN" could have avoided that minor nuisance easily.
Nothing is impossible if you don't need to do it yourself.

IETF Opus codec now ready for testing

Reply #395
I guess a minor workaround would be to change the least significant digit of one of the gain figures by the smallest increment possible to make them different values in fb2k. It's a fudge, but it might be possible with no audible change. Another option might be to add a non-standard comment field to indicate that Album Gain Equals Track Gain = TRUE while not specifying an Album Gain figure as it's 'prohibited' (which is a nice way to force Opus players to support at least some form of volume normalization, so I can see why it's worthwhile).
Dynamic – the artist formerly known as DickD

IETF Opus codec now ready for testing

Reply #396
Current (dev) builds of rockbox now have preliminary support for Opus.  The current code has zero optimizations, so older devices probably won't be able to play it without skipping, but thats normal for new codecs before they get rewritten for ARM

IETF Opus codec now ready for testing

Reply #397
how does Rockbox resample from Opus' 48kHz to its own 44.1?

IETF Opus codec now ready for testing

Reply #398
Current (dev) builds of rockbox now have preliminary support for Opus.  The current code has zero optimizations, so older devices probably won't be able to play it without skipping, but thats normal for new codecs before they get rewritten for ARM

Not sure whether there is much sense to keep  development for old devices.  DAPs start to see their end while the sales of smartphones grow.  Today the  vast majority of smartphones have powerful CPUs.

Have tried Opus on phone with Android  http://rasher.dk/rockbox/android/ . Works well and has plenty of battery life.
Probably the battery life isn't an issue anymore.  Anyway people should recharge it (almost) every day.


IETF Opus codec now ready for testing

Reply #399
Current (dev) builds of rockbox now have preliminary support for Opus.  The current code has zero optimizations, so older devices probably won't be able to play it without skipping, but thats normal for new codecs before they get rewritten for ARM

Not sure whether there is much sense to keep  development for old devices.  DAPs start to see their end while the sales of smartphones grow.  Today the  vast majority of smartphones have powerful CPUs.

Have tried Opus on phone with Android  http://rasher.dk/rockbox/android/ . Works well and has plenty of battery life.
Probably the battery life isn't an issue anymore.  Anyway people should recharge it (almost) every day.


I did some tests with a earlier version of rockbox-opus (it should still be valid since there still no optimizations on code) on a Samsung Galaxy S II (http://www.hydrogenaudio.org/forums/index....st&p=805855, just for update I did compile using ARMv7 optimizations and NEON fpu, but didn't see any increase of performance, probably because Rockbox uses the integer version of Opus decoder) and it shows that optimizations would be really welcome. Opus on Rockbox simple use too many cycles even on a fast (1,2GHz) dual-core, ARMv7 processor, so while it's capable to decode even the highest bitrate sample with easy, it simple uses too many cycles and uses too much power (my CPU gets really hot when playing Opus files). My Sansa Clip+ was clearly using more power to play Opus files than Vorbis too.

Either way, Opus is designed for embedded devices in mind, so with properly optimizations maybe it will use less CPU to decode Opus than even MP3 on future.