IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 14 15 16 17 18 > »   
Closed TopicStart new topic
IETF Opus codec now ready for testing, That's CELT 0.11
darkbyte
post Sep 6 2012, 16:38
Post #376





Group: Members
Posts: 145
Joined: 14-June 11
Member No.: 91517



QUOTE (LithosZA @ Sep 6 2012, 14:28) *
Weird, does CVBR do the same?

I'll try this out later.

QUOTE (Martel @ Sep 6 2012, 14:40) *
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.

QUOTE (jmvalin @ Sep 6 2012, 15:31) *
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.

QUOTE (LigH @ Sep 6 2012, 15:34) *
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 smile.gif


--------------------
Wavpack -b450x1c
Go to the top of the page
+Quote Post
softrunner
post Sep 7 2012, 02:31
Post #377





Group: Members
Posts: 48
Joined: 19-July 12
Member No.: 101579



QUOTE (NullC @ Sep 4 2012, 22:55) *
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).
Go to the top of the page
+Quote Post
saratoga
post Sep 7 2012, 02:41
Post #378





Group: Members
Posts: 4853
Joined: 2-September 02
Member No.: 3264



QUOTE (softrunner @ Sep 6 2012, 21:31) *
Why "--music" option was removed?


http://www.hydrogenaudio.org/forums/index....st&p=805845

Go to the top of the page
+Quote Post
Dynamic
post Sep 8 2012, 17:58
Post #379





Group: Members
Posts: 795
Joined: 17-September 06
Member No.: 35307



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?
Go to the top of the page
+Quote Post
LigH
post Sep 12 2012, 12:10
Post #380





Group: Members
Posts: 154
Joined: 20-November 01
Member No.: 503



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...


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
Silversight
post Sep 14 2012, 12:36
Post #381





Group: Members
Posts: 310
Joined: 5-April 06
From: Aachen, Germany
Member No.: 29203



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

This post has been edited by Silversight: Sep 14 2012, 12:41


--------------------
Nothing is impossible if you don't need to do it yourself.
Go to the top of the page
+Quote Post
NullC
post Sep 14 2012, 13:17
Post #382





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Silversight @ Sep 14 2012, 03:36) *
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.
Go to the top of the page
+Quote Post
Silversight
post Sep 15 2012, 01:28
Post #383





Group: Members
Posts: 310
Joined: 5-April 06
From: Aachen, Germany
Member No.: 29203



QUOTE (NullC @ Sep 14 2012, 14:17) *
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
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

This post has been edited by Silversight: Sep 15 2012, 01:52


--------------------
Nothing is impossible if you don't need to do it yourself.
Go to the top of the page
+Quote Post
Undesirable
post Sep 15 2012, 06:28
Post #384





Group: Members
Posts: 76
Joined: 26-December 02
Member No.: 4239



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 (maxmp)
Actually, we're looking into adding it. Most probably will be in the next intermediate build.
Thanks!

Go to the top of the page
+Quote Post
foxyshadis
post Sep 15 2012, 08:07
Post #385





Group: Members
Posts: 42
Joined: 28-March 06
Member No.: 28917



QUOTE (Silversight @ Sep 14 2012, 03:36) *
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.
Go to the top of the page
+Quote Post
Silversight
post Sep 15 2012, 08:53
Post #386





Group: Members
Posts: 310
Joined: 5-April 06
From: Aachen, Germany
Member No.: 29203



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.
Go to the top of the page
+Quote Post
NullC
post Sep 17 2012, 02:35
Post #387





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Silversight @ Sep 14 2012, 17:28) *
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.

QUOTE (Silversight @ Sep 15 2012, 00:53) *
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.

This post has been edited by NullC: Sep 17 2012, 02:44
Go to the top of the page
+Quote Post
Silversight
post Sep 17 2012, 11:41
Post #388





Group: Members
Posts: 310
Joined: 5-April 06
From: Aachen, Germany
Member No.: 29203



QUOTE (NullC @ Sep 17 2012, 03:35) *
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.

QUOTE (NullC @ Sep 17 2012, 03:35) *
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.
Go to the top of the page
+Quote Post
Dandruff
post Sep 17 2012, 12:10
Post #389





Group: Members
Posts: 493
Joined: 20-April 04
Member No.: 13618



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

192kbps VBR maybe?
Go to the top of the page
+Quote Post
maikmerten
post Sep 17 2012, 12:36
Post #390





Group: Members
Posts: 219
Joined: 12-February 02
Member No.: 1312



QUOTE (Dandruff @ Sep 17 2012, 12:10) *
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).
Go to the top of the page
+Quote Post
skamp
post Sep 17 2012, 12:36
Post #391





Group: Developer
Posts: 1410
Joined: 4-May 04
From: France
Member No.: 13875



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.


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
Dandruff
post Sep 17 2012, 12:47
Post #392





Group: Members
Posts: 493
Joined: 20-April 04
Member No.: 13618



Ok, thanks. I wan't to use it for my mobile music library.
Go to the top of the page
+Quote Post
LigH
post Sep 17 2012, 12:53
Post #393





Group: Members
Posts: 154
Joined: 20-November 01
Member No.: 503



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...


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
Dandruff
post Sep 17 2012, 13:26
Post #394





Group: Members
Posts: 493
Joined: 20-April 04
Member No.: 13618



Ok, thanks! I've always used the original Ogg Vorbis Encoder ...
Go to the top of the page
+Quote Post
Silversight
post Sep 20 2012, 14:30
Post #395





Group: Members
Posts: 310
Joined: 5-April 06
From: Aachen, Germany
Member No.: 29203



QUOTE (Dynamic @ Sep 8 2012, 18:58) *
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.
Go to the top of the page
+Quote Post
Dynamic
post Sep 20 2012, 19:22
Post #396





Group: Members
Posts: 795
Joined: 17-September 06
Member No.: 35307



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).
Go to the top of the page
+Quote Post
saratoga
post Sep 21 2012, 16:07
Post #397





Group: Members
Posts: 4853
Joined: 2-September 02
Member No.: 3264



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 smile.gif
Go to the top of the page
+Quote Post
lvqcl
post Sep 21 2012, 19:35
Post #398





Group: Developer
Posts: 3327
Joined: 2-December 07
Member No.: 49183



how does Rockbox resample from Opus' 48kHz to its own 44.1?
Go to the top of the page
+Quote Post
IgorC
post Sep 21 2012, 21:04
Post #399





Group: Members
Posts: 1533
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (saratoga @ Sep 21 2012, 13:07) *
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 smile.gif

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.

Go to the top of the page
+Quote Post
m45t3r
post Sep 22 2012, 01:09
Post #400





Group: Members
Posts: 22
Joined: 14-January 12
Member No.: 96431



QUOTE (IgorC @ Sep 21 2012, 17:04) *
QUOTE (saratoga @ Sep 21 2012, 13:07) *
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 smile.gif

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.

This post has been edited by m45t3r: Sep 22 2012, 01:14
Go to the top of the page
+Quote Post

23 Pages V  « < 14 15 16 17 18 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th July 2014 - 10:09