Hi!

OptimFROG Dual Stream is aimed at filling the big gap between
perceptual coding and lossless coding. The goal is to offer real
transparent audio coding (not only perceptually transparent) at
half or less the bitrate generally used by lossless coding, and
also to permit progressive consistent increase of the quality
level, until lossless coding is reached.

To eliminate the eternal problem of choosing between lossless and
near lossless, it has an option to create a correction file, which
may be eventually stored separately and used at a later time to
restore the original. The advantage is that the two files, OFS and
OFC have together approximately the size of the lossless coded
original file (slightly greater with up to 1%).

OptimFROG Dual Stream is in alpha stage. Although it was intensively
tested on 39 audio CDs, I am still searching for hidden problems.

It is a branch from the main OptimFROG version 4.506 project, with
modifications to allow the extended functionality and different
file extension (OFS - OptimFROG Small) in order not to mix lossless
and lossy files. I am not sure if it will remain a separate branch
or it will merge into the main project.

Feedback is greatly appreciated, especially problem reports with
the program crashing or worse, producing audio "garbage" (very
bad quality audio files).

I would like to thank to David Bryant, the Wavpack author
for the idea of the correction file (a file which, when used
combined with the lossy file, permits lossless restoring of
the original file).
Although the two programs have common user functionality, they
are based upon very different principles. There is almost no
similarity between their implementation.
Also, thanks for his great program which made me consider
finishing and opening to the public OptimFROG Dual Stream, of
which first working version I did more than a year earlier,
in April 2002.

Download it (Win32 console+foobar2000+Winamp2) from
http://losslessaudiocompression.com/Downlo...m_4507a_zip.php
You may check all the the details directly at
http://losslessaudiocompression.com/DualStream.php
or by visiting http://losslessaudiocompression.com

Florin Ghido

Hmmmmmmmm. Looks interesting. I'm just downloading a copy now to check it out further. Might post an opinion or two once I've played with it for a while.

Thanks,

Den.

Interesting, indeed. Congratulations, Ghido.
It seems that Mr. Roberto Amorim was right and this is the way for the lossless codecs...

Some early test results:

Took bryant's furious sample, which seems to be one of the few samples that Wavpack lossy actually screws up. Wavpack lossy has trouble with this up to and including 400 kbits, but it gets better (not transparent) with 400 kbits and joint stereo enabled.

ofs --quality 0 --mode extra furious.wav, yields a 181 kbit file, that I can not readily ABX... (No obvious artifacts).

I now have a few other things I want to try. Only one complaint so far...it's very slow, and on my PC, seeking is worse than Wavpack.



Den.

What algorithms are you using in lossy mode? Quantization only, like WV? Some sort of psychoacoustic model? DCT?

@AngelGR: Thanks.

@Ghido

Looks like Roberto beat me to it, regarding asking you what techniques are used. I can't easily hear additional noise/hiss, like I often do with Wavpack lossy. I haven't extensively tested it yet though...

Den.

This sounds awesome. Great idea, expanding on the wavpack-hybrid theme!

I don't have time to test for a few days, hopefully i can check it out asap.

Wow this new lossless+lossy is like a revolution! Very exciting stuff indeed

Sounds very good even with --quality 0. And the udial sample (with the strong high-pitched tones) doesn't fool this new lossy mode at all!

What about trying some of MPC's problem samples?

Well, instead I found another problem sample for both optimfrog and wavpack lossy. It's not quite music but maybe interesting anyway: keys from the pcabx site. Both lossy encoders add a lot of audible noise to the key-jangling.

Den: I look forward to hearing your results.

Yeah ... sounds good ... Idea is good ... BUT after some tests I realize that --seek, --optimize and --mode
keys effect lossy compression time and ratio. These keys work good for lossless but I think it's too much for
lossy because it's hard to determine which combination will give best results. I think Ghido you must simplify
not only lossy but lossless options too. But anyway good job !

PS: does it mean that extension .ofr changed to .ofs ?
Why in_ofs doesn't play .ofr ?

PSS: Oh Shit, looks like it's needed to use both in_ofs and in_ofr. I think Ghido you must restructure your
project ...

Good sample! It's actually a little like the "furious" sample, but more noise and less tone in the high frequencies.

Using noise shaping in WavPack (-s1) makes this almost perfect, but I don't approve of using custom command lines to generate good results.

I agree with regards to custom command lines. I know it's a big ask when I have zero experience in programming a codec, but it's best when an encoder can detect special cases and adjust to suit automatically, unless this is deliberately overridden by the user.



OK, some initial findings. My initial interest in this was to see whether it transcodes into ATRAC (for Minidisc) as well as Wavpack lossy does. I ripped/encoded/transcoded Blue Monday - New Order and listened to it all the way through, plus conducted some blind ABX tests on the final transcoded ATRAC3 track against that encoded direct from the wavs, ie

1. wav -> DualStream --quality 3 (350 kbits) -> ATRAC3 and
2. wav -> DualStream --quality 2 (318 kbits) -> ATRAC3 and
3. wav -> DualStream --quality 1 (287 kbits) -> ATRAC3 and
3. wav -> DualStream --quality 0 (259 kbits) -> ATRAC3 and
4. wav -> ATRAC3.

I could not ABX with --quality 2 and 3 against the directly ATRAC encoded wav, which is the same for Wavpack lossy @320 handled the same way. At --quality 0 and 1, I think I was occasionally picking up some background noise around some notes, but I was not consistently getting it correct. So DualStream compares very well against Wavpack lossy for transcoding purposes, and both of them leave Vorbis q10, mpc q10 and LAME insane behind in terms of introduced transcoding artifacts.

Repeated above with Relax - Frankie goes to Hollywood using quality 2 and 0 (346 - 247 kbits). They all sounded fine on Minidisc and could not be readily discerned from the same direct encoded from wav.

I then encoded and transcoded 3 CDs across to ATRAC3 via DualSteam quality 2, which generated ofs files between 261 - 324 kbits. (The 3 CDs were Stan Ridgeway - Songs That Made This Country Great, New Order - Substance CD1 and Moby - Play) These were then listened to all the way through, and the quality was excellent, with no noticeable artifacts through relaxed, but attentive listening. B)

DualStream certainly transcodes very well (like Wavpack lossy) at similar, and sometimes lower bitrates. What doesn't help though is the slow encoding/decoding speed, but this will hopefully improve in newer versions. I can normally decode and replaygain 2 hours 40 minutes of music for MD in about 5-10 minutes with Wavpack lossy. This takes nearly an hour with DualStream on my aging Duron 750 MHz.

Now for some ABX tests with DualStream directly against the original wavs. Watch this space.
>_<
Den.

Right. Just took the opening 20 seconds of Stan Ridgway - Lonely Town. This section features a bluesy intro with some sliding and picked electric guitar, and percussion instruments. It is well recorded and has plenty of space in between the notes that allows me to pick up noise or hiss.

ofs --quality 0, resulted in a 251 kbit file. ABX results - 11/15 first time, then 15/15 and 15/15.
ofs --quality 1, resulted in a 284 kbit file, ABX results - 6/15 first time, then 13/15 and 14/15.
ofs --quality 2, resulted in a 319 kbit file, ABX results - 8/15, 9/15, 8/15.

Very nice. At quality 0, there was slight noise around the notes. It wasn't fuzzy, just background noise, and I had to listen very closely to pick it. It seemed to come in and out around each note, rather than as a blanket background hiss like I tend to detect in wavpack lossy. At quality 1, I thought the noise had gone at first, but after I tried harder, my ability to pick it improved.
At quality 2, forget it. It was completely transparent as far as I was concerned.

Just to confirm that my ears were not broken, I also repeated the above with Wavpack lossy.

wavpack @265 kbits (actual was 271 kbits), ABX results 15/15. Background hiss.
wavpack @320 kbits, ABX results 15/15. Background hiss.
wavpack (3.97 experimental) @271 kbits (actual was 271 kbits), ABX results 8/15, 10/15, 10/15.

Nothing like a little healthy competition. Time for some more testing. B)

Den.

Another sample which causes a hiss problem with both DualStream and Wavpack lossy is the opening sequence of Ring Of Fire - Stan Ridgway. I will post it somewhere when I get to my other PC.

ofs --quality 2, 293 kbit file. ABX 15/15, no practice required. Distinct change in the background hiss. Very similar to that from wavpack lossy 3.97 at similar bitrate.

wavpack lossy @265, actual file was 272 kbit. ABX 15/15, again distinct hiss, no practice required to pick it. Same again with noise shaping enabled in the experimental version.

Of the two, preferred the ofs version, as hiss was slightly more subtle, but still very easy to pick.

Repeated with ofs --quality 3, 4 and 5.

ofs --quality 3, 310 kbit file. ABX 15/15 first attempt. Hiss.
ofs --quality 4, 348 kbit file. ABX 14/15 first attempt. Hiss. Getting more subtle now, but still clearly there.
ofs --quality 5, 388 kbit file. ABX 9/15 first attempt. Repeated 11/15, and then 12/15. Getting hard now.

wavpack @320. ABX 13/15, then 15/15. Hiss.
wavpack @388. ABX 15/15 Hiss.
wavpack (experimental with noise shaping). ABX 11/15. then 14/15. Much better than the other Wavpack attempts, but still there if you listen carefully. >_<

It would appear with this sample, (pulsing distorted guitars?) that the hiss is more prevalent with both, but if you throw more bits at it, DualStream comes out slightly better, sooner.

The noise shaping option in experimental Wavpack lossy certainly improves things over straight 3.97, but this is not probably an ideal sample to try the shaping option out on.

Den.

Nice work Florin! I've made a front-end for this new encoder:
http://home.wanadoo.nl/~w.speek/download/F...ntendOFR-DS.zip

Blimey Den, you have been busy! Thanks a lot. Interesting stuff.

Between DualStream and Wavpack lossy, plus 4.00 on it's way, there is plenty of interesting development going on. By the way, the sample I ABX'ed is here in Wavpack lossless format..

Den.

Nice work Speek! Makes playing with DualStream a whole lot easier...



Well Roberto, curiosity killed this cat (or dog actually) again and I conducted a little experiment with Wavpack lossy and DualStream. (Love that name...)

Take x.wav and encode with wavpack lossy. Decode resulting file into a wav file (#1), then reencode #1 with the same Wavpack lossy settings. Decode resulting file into a wav file (#2). Compare wavs #1 and #2 with EAC and you will find they are bit for bit indentical. (HA regulars already know this from atici's post in the MPC section.)

Repeat the above with Dualstream, and you get two identical sized wav files, but when you do a comparison with EAC, they are very different inside.

What does this mean? Buggered if I know, but I guess there is some modelling going on in there somewhere, compared with Wavpack's straight predictor based approach.

Just out of interest, I also repeated the Wavpack experiment with noise shaping enabled on an experimental version, and bingo, they still match.

Fascinating... B)

Den.

But wait, there's more.

I can't leave this and the experimental Wavpack lossy encoder alone at the moment.

It occurred to me that the test conducted before is not necessarily fair (apples vs oranges ), in that it was comparing CBR (Wavpack) against VBR (DualStream quality mode) so I repeated my tests.

Wavpack @270 kbits (actual 273 kbits) : ABX 15/15. Very distinct elevated background hiss. Annoying.
Wavpack @320 kbits (actual 315 kbits) : ABX 15/15. Same as above, but hiss was not as annoying, still obvious.
Wavpack @400 kbits (actual 400 kbits) : ABX 15/15. Hiss quite soft now, but still readily detected.

All the above was conducted in high quality mode, no shaping, no joint stereo.

Wavpack X @270 kbits (actual 273 kbits) : ABX 15/15. Very distinct elevated background hiss. Better than Wavpack 3.97 but still annoying.
Wavpack X @320 kbits (actual 315 kbits) : ABX 15/15. Same as above, but hiss was not as annoying, still obvious. Again, better than 3.97.
Wavpack X @400 kbits (actual 400 kbits) : ABX 12/15, then 13/15. Need to concentrate now, but can still be detected if I listen carefully at high volumes.

Each of these were better than the corresponding 3.97 version by varying degrees. The "relocatable" noise shaping option seems to offer some benefits during my early tests. If you decide to play with it, most music benefits with a -s0 to -s-1 type setting. -s1 has made every sample from my music collection much worse so far. :x

ofs --bitrate 270 kbits (actual 270 kbits) : ABX 15/15. Distinct background hiss. Quite annoying. Comparable to Wavpack X with noise shaping enabled.
ofs --bitrate 320 kbits (actual 319 kbits) : ABX 15/15. Hiss is reduced, but clearly there. Not annoying, but clearly there.
ofs --bitrate 400 kbits (actual 399 kbits) : ABX 8/15, then 9/15. Pretty damn close!

On a whim, I also conducted "ABX" tests within foobar with Wavpack X vs DualSteam equivalent.

@ 270, could ABX 15/15, Dualstream was slightly less annoying, hiss slightly softer.
@ 320, could ABX 15/15, Dualstream was slightly less annoying, hiss slightly softer.
@ 400, could ABX 15/15, Dualstream by a nose, because I could still barely detect hiss in Wavpack X, but not Dualstream.

All of these tests were with Ring Of Fire intro. Same as before. Rather than post further test results here, I will probably start a new thread when I have something else to report.

For now, I am staying with Wavpack because of the speed benefits, but will split my encodes 1/3 Wavpack 3.97, 1/3 Wavpack X and 1/3 Optifrog DualStream in order to get a range of comparisons between the three.

Hope this is useful to someone out there.

Den.

If I got this explanation right, no psychoacoustic or even noise shaping is performed (difference is pure white noise).

@den: could you perform this test with reencoding (for being bit-identical) with CBR OFS files? I think some chances are...

-Eugene

not tech stuff but, .ape tagging support would be good

It may be just a difference as white noise, but it isn't using a straight predictor method like Wavpack lossy otherwise you would get identical files like you do from reencoding a decoded Wavpack encoded file, if you catch my drift.



... that they are completely different. I did the test with CBR using the --bitrate 320 switch. I just repeated it then for my own peace of mind. Using the quality switch to do this, being VBR, did not make sense.

Just to clarify, I took my test wav, and encoded it using ofs --bitrate 320 test.wav.
Took resulting ofs file, and decoded it back into another wav. (Call this wav2).
Took wav2 and encoded again using ofs --bitrate 320 wav2.
Took resulting ofs file and decoded into another wav. (Call this wav3).

Compare wav2 and wav3 in EAC. Each is completely unique.

As I said, fascinating. B)

I'd love to read some comments from ghido on this!

Den.

Supports Ape V2, and Speek's fantastic front end adds them for you.

Den.

Mhhh..but I can't add them with EAC as Ido when I use MPC.

Hi!

First, thank you all for the great feedback, testing and samples...

There are great news regarding the latest OptimFROG DualStream, version 4.507a2:
- added advanced noise shaping at encoding (--ans) option, improving transparency, especially at lower bitrates
- 210% faster encoding in quality mode at bit identical results
- 220%-270% faster encoding in average bitrate mode at bit identical results

Get it from http://LosslessAudioCompression.com on the DualStream page


As opposed to WavPack which does implicit modeling by varying the quantization level to maintain the desired data rate, OptimFROG DualStream has an explicit advanced modeling stage. The model is not similar with a psychoacoustic one and it uses quite new techniques which try to minimize both objective and subjective (perceptual) information loss (which I do NOT intend to describe further for the moment). The output from the model (qantization level) is in some way written as side information in the compressed file, for the decoder to use it without further analysis. This has the great advantage of a very fast decoder, backward (implicitly) and forward (older decoder plays newer version streams) compatibility and permits enhancing encoding (modeling phase) without disrupting the users.

There had been relatively some confusion about using --quality with --mode extra (probably thinking that it produces slightly better "quality" than using only --quality), the starting point of the idea that DualStream is implacably slow. I did an example test to clarify this situation (using DualStream 4.507a2 and WavPack 3.97 and taken from the ofs.txt readme file):

There it is a short, speed illustrative example (test file used was
Yes - The Ladder - New Language, duration 9m19.1s):

No. Bitrate Enc. Dec. Command line used for encoding
1. 341.0 kbps 26.9x 31.4x wavpack -h -b340
2. 345.9 kbps 12.8x 23.7x ofs --mode fast --quality 3
3. 341.0 kbps 9.7x 16.7x ofs --quality 3
4. 338.3 kbps 5.2x 8.0x ofs --mode extra --quality 3
5. 244.0 kbps ofs --mode fast --quality 0
6. 241.0 kbps ofs --quality 0
7. 239.2 kbps ofs --mode extra --quality 0

Note that for (2),(3), and (4) compressed files decode to the same
bit-identical file, so there is absolutely NO sacrifice in quality
by using either file. The only difference is that the fast mode file
has it this case 5 kbps greater bitrate than normal mode, and extra
mode file has 3 kbps smaller bitrate than normal mode.

When speed is of primary concern, you may use --mode fast along with
the desired quality

When you have a very high speed computer and speed does not matter
much, you may use --mode extra along with the desired quality, which
will save a few more kbps compared to normal mode, especially at very
high quality settings (quality>=5). Using --mode extra with
quality<=3.0 generally shows no significant kbps savings (<=3 kbps)
and generally does not worth using (see positions (5), (6), and (7))


As a conclusion, OptimFROG DualStream is not as slow at it may first seem (probably because of the horrible encoding speed of the first alpha 4.507a), just 30% slower decoding at its fastest mode than WavPack...


As I stated in the readme, I did not want to mix this new alpha (experimental) files with the highly stable OptimFROG standard. Also, .ofr extension was thought as and I think it should always remain so, lossless.
Future plug-ins will play both of the files (if you rename .ofr extension to .ofs they will be played by the ofs plug-in right now)
Regarding OptimFROG (DualStream) having too many options, I recommend limiting to the --mode option for the standard version and to the --quality option (eventually with --ans) for the DualStream version.
The default values for the parameters generally give the best overall performance (time and compression). These recommended "presets" are given at the end of the corresponding readme file.

@Speek: Great job, thank you very much for adding the front-end for DualStream...

@Den: Thank you very much for your detailed ABX testing and samples. There is the new advanced noise shaping --ans mode for you to test B), which does adapt noise to stay in the "shadow" of the signal.
This is similar to the Wavpack X option (-s-1 ... -s0 ... -s1) but unlike it, is not limited to a straight line balanced attenuation, as it may take more complex forms following the signal, and it adapts continuously to the music encoded. Using a fixed shaping option like WavPack's -s may present the danger of lowering the quality of some portions of the encoded file without knowing, because ANY constant value will produce worse results on some portions of the same file than the no shaping option.

I find very interesting the WavPack property of reencoding the decoded lossy file identically. However, the problem is that if you modify even one single sample of the file, it does completely lose this property (after the respective sample)...

Thanks again for the your enthusiasm and encouraging. I'm waiting for your feedback...

Florin

Excellent. Am downloading it as I type. B)



You're welcome. I'm grateful for your and David's efforts with these encoders, their transparency for transcoding from into other lossy formats is very, very useful in my daily music routine.

I believe automatic noise shaping is very important for these types of encoders. There is plenty of opportunity to hide the noise within and around the signal with most music, which as you say should significantly improve transparency if it can move around to stay hidden. Blanket noise shaping can help if the signal has the bulk of its frequencies within a certain band, but most music isn't like that. The noise shaping should also cut in and out as required. Some samples don't need it after all.



It's a pretty neat party trick, but it has no use in the real world. It just gives some hints as to how the encoder works. I wouldn't have even known about it if it wasn't for something someone raised in a MPC thread and David was kind enough to explain it. I thought that seeing as Wavpack did it and yours didn't, there was clearly some different stuff in there.

Will do some testing and revert.

Den.

Try Case's wapet.

http://www.saunalahti.fi/~cse/files/wapet.zip

No noise shaping can also be interesting for editing purposes, because, as widely known , editing can break some assumtions made at encoding. (Oh, and I assume that OFS quality is high enough for editing )

-Eugene

OK, just completed another round of ABX tests using the --ans option.

Conducted tests on three samples, Ring Of Fire (intro) - Stan Ridgway, Bad Man's Song (intro) - Tears for Fears and Bittersweet Symphony (intro) - The Verve. (See a pattern here? I always find it easier to pick these encoders with intro, or solo instrument sections in the music.)

First, let's go for Ring Of Fire:

ofs --quality 0: (216 kpbs) ABX 15/15. Distinct hiss. Quite clear, and annoying.
ofs --quality 0 --ans: (201 kpbs) ABX 15/15. Similar to the above sample.
ofs --quality 2: (276 kpbs) ABX 15/15. Hiss still there but much softer than either quality 0 case.
ofs --quality 2 --ans : (265 kpbs) ABX 15/15. Hiss, slightly less agiain, but virtually same as --quality 2.
ofs --quality 3: (310 kpbs) ABX 15/15. Very slight hiss. Very subtle, but it's there.
ofs --quality 3 --ans: (301 kpbs) ABX 15/15. Again virtually identical to straight quality 3 sample, but at a lower bitrate?
ofs --quality 4: (348 kpbs) ABX 14/15. Very subtle change in background noise cf orignal wav.
ofs --quality 4 --ans: (344 kpbs) ABX 15/15. Also very subtle. Sounds same as straight quality 4.

Interesting to note the decrease in bitrate, especially at the lower quality settings. At quality 0, 1, the --ans option provides a bitrate benefit, but no obvious quality gain. I guess the encoder aims for a certain S/N or quality target, so switching --ans on with --quality tends to push the bitrate down but still yields a similar quality.

Next sample, badman intro.

ofs --quality 0: (250pbs) ABX 15/15. Some hiss, but not as obvious as other samples at same bitrate.
ofs --quality 0 --ans: (242 kpbs) ABX 15/15. Similar to the above sample, but slightly lower bitrate.
ofs --quality 2: (323 kpbs) ABX 15/15. Very close, closer than score suggests. Very, very slight hiss.
ofs --quality 2 --ans : (318 kpbs) ABX 15/15. Again sounds virtually indentical to above but less bits used.

Didn't bother with quality 3 test, was keen to move on to next sample.

Bittersweet intro.

ofs --quality 3: (335 kpbs) ABX 15/15. Slight noise hugging around the notes.
ofs --quality 3 --ans: (330 kpbs) ABX 15/15. Again virtually identical to straight quality 3 sample, but at a lower bitrate.

I'm going to stop and repeat these samples with fresh ears tomorrow and use CBR, so that the effect of --ans is more obvious, rather than the encoder hitting the same quality with less bits.

I was surprised at first to not be getting any obvious quality gain from --ans, but it would appear that when used with the --quality switch, ans simply allows it to hit the same quality with less bits, resulting in a very similar encoded file quality, with or with out ans.

Oh well, that's one way to kill an evening...

Den.

PS: Also, this newer version has significantly faster encoding/decoding, thank goodness. B)

Is it me or is using "--correction --ans" broken?

when i use these 2 together no correction file is produced.

full command line

ofs --quality 0 --correction --ans *.wav

Yep, broken here too.

Also tried changing the order of the switches, same result.

Den.

hehe.... eternal? i can just picture some cavemen arguing over the merits of lossless and near lossless encoding over a meal.

It would be broken if it crashed or produced incorrect results. But it is only disabled (because I did not implemented it yet , as it must be treated differently). Don't worry, there will be correction files for every mode. But remember, it's just an alpha...

@den: Just curious. Any news with ABX results at average bitrate?

However, watch out as there are more interesting things to come...


Or maybe even better, talking about the need of audio compression...

Thanks,
Florin

OK, some results for ABX tests with --ans. Overall a bit of a mixed bag with --ans.

I used three samples: Badman's Song, Bittersweet Symphony and Ring Of Fire.

First Badman's Song.

ofs --bitrate 275 : ABX 15/15. General background hiss. Not annoying, but there.
ofs --bitrate 275 --ans : ABX 15/15. Hiss still quite obvious, but sounds slightly different than without --ans. Not really any better.
ofs --bitrate 320 : ABX 15/15. General background hiss, and some noise ducking in and out around the tom toms. Couldn't really pick this at 275 because of general hiss.
ofs --bitrate 320 --ans : ABX 15/15 Very similar to above, but noise around the notes was slightly different, and perhaps a little harder to pick?
ofs --bitrate 400 : ABX 15/15. Still very slight noise trailing and coming in and out around tom toms. Quite hard to pick, but it's there.
ofs --bitrate 400 --ans: ABX 7/15, 8/15 Transparent. B)

So with this sample, --ans didn't really help, or hinder the encoder's ability to get transparency until 400.

Next Bittersweet Symphony

ofs --bitrate 275 : ABX 15/15. Blanket hiss. Cello line does not quite sound the same. (See below)
ofs --bitrate 275 --ans : ABX 15/15. Blanket hiss, no real improvement over straight up. Cello sound still different.
ofs --bitrate 320 : ABX 15/15. Less hiss, but still there. Slight noise around the notes.
ofs --bitrate 320 --ans : ABX 8/15. 9/15 8/15 B) Transparent.
ofs --bitrate 400 : ABX 9/15, 10/15, 7/15. Transparent B)
ofs --bitrate 400 --ans : ABX 9/15, 8/15. Transparent B)

Here, --ans kicked in and made 320 transparent. Certainly offers a benefit over straight encode.
At 275, apart from the blanket hiss, the cello line was not quite as rich. This is difficult to explain, but when I listen to the wav, I get goosebumps on my arms and a shiver down my spine with this sample. At 275 with Wavpack and Dualstream, I don't get the goosebumps. The cello sounds the same, but it does not seem as rich and enjoyable to listen to.

Finally Ring of fire

ofs --bitrate 275 : ABX 15/15. Blanket hiss. Almost annoying.
ofs --bitrate 275 --ans : ABX 15/15. Blanket hiss. Slightly less annoying than above, almost as if the hiss has less of an "edge" to it.
ofs --bitrate 320 : ABX 15/15. Blanket hiss. Quite noticeable but not annoying. A hint of noise moving around with the pulsing distorted guitar.
ofs --bitrate 320 --ans : ABX 15/15. Hiss is still there, but is now clearly moving with the pulsing distorted guitar, and is actually now more noticeable than without ans.
ofs --bitrate 400 : ABX 15/15. Hiss is still there, and some slight noise still around the guitar.
ofs --bitrate 400 --ans : ABX 15/15. Similar to above. Again, the hiss and some other noise is now moving slightly with the pulsing, and is very slightly more annoying than without.

This sample is generally less transparent even at higher bitrates because of the blanket background hiss generated, and with --ans, it moves around with the signal and is almost more noticeable.

So there you have it. My general opinion of Dualstream so far is as follows:
1. It generally hits transparency at a lower bitrate than Wavpack lossy. The margin varies depending on the samples and bitrate range you are working within, but I often find that Dualstream @ 275 is similar to Wavpack lossy @ 320 in many cases. As you get up towards 400 kbits, they converge.
2. The quality mode of Dualstream is very consistent, ie if you choose quality 3, you will get a similar resulting file quality, for most samples, just some will use more bits than others. If you want consistent quality encodes, it is the way to go over --bitrate, or Wavpack lossy with it's fixed bitrate.
3. The --ans switch will often save a few bits in quality mode for similar sounding files. If you use it with CBR/ABR, it's performance depends on the sample. For melodic music it seems to work quite well. For unusual, pulsing type tones, or music with space between sharp attacks you may here some movement in the hiss. My gut feeling is to use for most encodes, but check it for yourself.

I was expecting --ans to give the most benefit at the lowest rates, but I found it was most effective in the 320 - 400 bitrate range, and at 275, there was enough general background hiss to disguise any real benefit from --ans.

One other disclaimer. I could ABX Dualstream readily because of its background hiss, just like I can with Wavpack lossy. I seem to readily pick this, where as others don't. You may find it transparent at lower rates than me. Like Wavpack lossy, I am not finding artifacts as such, just subtle changes in the background noise/hiss.

Hope this helps. B)

Den.

No........ Not more tests!

Bring it on! B)

Den.

Thank you, Ghido for your efforts!

Maybe the lossy modes of Optimfrog and Wavpack could be especially attractive to people conserving their LP collection (or similar) who fear the effects of psychoaccoustic compression, but want to conserve space. Maybe they also allow more postprocessing. This should be evaluated.