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: lossyWAV 1.3.0 Development Thread (Read 195176 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lossyWAV 1.3.0 Development Thread

Reply #125
lossywav […]
Its advantages are tied to the use of lossless codecs:
- potential broader hardware support & future proof hardware support.
- 100% safe gaplessness (for exemple, despite its audio quality, Nero AAC is not 100% safe regarding gaps with some tag editors. I tested with MP3tag, but it's likely true with even more obscure tag editors)
- the ability to split & join losslessly (no classic lossy codec can do that due to breaking gaps, I tested with vorbis & nero aac, I dunno & don't care for musepack)
- the above make lossywav the only lossy codec usable as CDImage+cue.

- "hybrid" mode ("correction file")

This means that transparency & bitrate is not everything in audio.

Glad to hear that. I think i needed to be reminded of this.

Although, MP3 (via LAME tag) and Vorbis (to my knowledge) support accurate and gapless splitting & rejoining. It's just that nobody has implemented tools for that yet. But the formats allow this.

[…]
The conclusion is that if your not ready to give up some bitrate for some flexibility, then you should not use lossywav.

I guesstimate the difference would be around 60kbit/s at similar quality levels and comparable psychoacoustic models. Obviously, it's not suited for very low bitrates but I think it scales nicely in the higher bitrate area and might be an option if you need a large noise/masking headroom for the warm fuzzy feeling in your tummy or just because you plan to further process the file while still saving some disk space.

Cheers!
SG

lossyWAV 1.3.0 Development Thread

Reply #126
I've been working on the adaptive shaping algorithm and have introduced a mechanism whereby the desired-shape changes gradually rather than totally every codec-block.

lossyWAV beta 1.2.2k attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #127
I've been working on the adaptive shaping algorithm and have introduced a mechanism whereby the desired-shape changes gradually rather than totally every codec-block.

lossyWAV beta 1.2.2k attached to post #1 in this thread.

Great! I've been a bit overwhelmed with various things lately so I apologise for not doing any testing in the last couple of days, but hopefully I'll manage to do some tests tonight.

lossyWAV 1.3.0 Development Thread

Reply #128
Just looking at some spectrograms, it looks as if lossyWAV 1.2.2k due to the new smooth noise shaping achieves rudimentary temporal post-masking, which is actually not unexpected at all because of the nature of this new kind of noise shaping wherein the signal from previous block affects the current block's noise shaping.

Whether the temporal post-masking was the intended goal behind the idea of smooth noise shaping or not I do not know, but it certainly is a nice by-product if it wasn't.

lossyWAV 1.3.0 Development Thread

Reply #129
Also I completely disagree with the theorical myth that lossywav would be suited for further transcoding with classic lossy codecs, this might be true but there is no real evidence of this. Furthermore it likely highly rely on which lossywav setting you used prior doing further transcoding. If you used lossywav near its transparency point as the first encode, I personnaly highly doubt that you can transcode it a second time with a classic lossy codec & get an as good result

In the far beginning of the development it was stated q7.5 and above, or -E and above are suitable to used as a source for lossy encoding. I think that this still is a fact. Although recent tests try to prove that even q3 and lower provide transparency; while meant for portable use, in noise environments. But maybe it's my hairdo, mood or English that I don't see a problem ?

My lossyflacs q8 and even q6 to lossy mp3 V1 are suitable enough for my dap (well, my wife's Sansa Clip).

lossyWAV 1.3.0 Development Thread

Reply #130
collector:
Sure old -q7.5 & -q5 can suffer a classic lossy generation loss without being distinguishable from pure lossless as a source, the safety margin here is large enougth. What I am saying is that I doubt that you can say the same for old -q2.5, because here there is almost no margin.

Now look at people signature:
Nick.C:
lossyWAV -P -t|FLAC -5: 378kbps
halb27:
RG | lossyWAV -q 3.5 --altpreset | FLAC -8 (409 kbps)

... myself, I didn't test lossywav recently because I can offer lossless, but I know that when I will come back to it, I will use something near the old portable setting.

Most people who use lossywav, seems to use it just like classic lossy: near its transparency point, so taking in account "transcodability" as a main argument for development is IMHO non-sense. The fact that -q7.5 & -q5 are easyly transcodable is nice, but it is not the main feature of lossywav according to me. Keeping compatibility with "transcodability" should IMHO not be something that prevents lowering the transparency point of lossywav.

For me "transcodability" is a nice side effect of the used technology of lossywav. Not a main feature.

I do not pretend to teach people how to use their files, but I am clearly saying that using -q2.5 for further transcoding to DCT codecs is a naive miss-use, ... if you use something slightly higher (I dunno say -q5), then I agree that transcoding would likely be unABXable from a pure lossless source. Personnaly, I just don't use lossywav for this feature, hence I don't really care for it.

I am not saying that there is no clever use of it for some people, I am just saying that it is such an unusual way of using audio that it should not hinder the development of more classic use of lossywav. (Like high quality lossy files for DAP supporting flac)

If at some point Nick.C must adopt some technology that make lossywav unsuited for transcoding, don't blame him for doing so, just ask for a special transcoding setting.

lossyWAV 1.3.0 Development Thread

Reply #131
I disagree.  You can use lower than a true transparency setting and still have un-abxable or near transparent transcoding . Its already being documented and tested . Read old wavpack articles by Den , myself , Guruboolez 350 ~ 400k tests and my recent tests showed losswav perform well even @ Q1.5 for transcoding. In fact the more you get into noise shaping and traditional psy stuff the more such things start to fall apart in my experience.

lossyWAV 1.3.0 Development Thread

Reply #132
Lossywav -q1.5 with further DCT transcoding transparent on Abfahrt Hinwil, Fool's Garden & Therion samples, when lossywav -q2 alone is already not transparent on these samples (I have posted plenty of ABXing logs that shows the weakness of lossywav on these samples below -q2.5 with old lossywav versions) ??? It's either lossywav has improved a lot since last time I tested it, or you're kidding me. Anyway I don't want to argue about listening tests (obviously you didn't listened the right samples), I actually don't plan to waste some time to prove my claims, so nevermind you're right (I am not joking you're probably right for yourself with the samples you tested, first I don't know about wavpack lossy I never tested it & then I admit I don't know how lossywav has evolved recently). I strongly encourage everybody to not trust anyone blindly (neither me or you, & even with valid ABXing logs because the choice of samples/earing skills/health(spleep, listening fatigue)/hardware ... can affect the possible conclusions a lot) & test for themselves.

Edit:
If you're arguing that you can transcode lossywav to another classic lossy codec without any additionnal loss due to this cross-codec transcoding itself (& not due to the original or target codecs/settings used whatever they may be). I highly doubt that any published test would be valid on a large scale. From a theoric point of view it is assumed that some of the cross-codec transcoding possible loss overlaps, but from a real life listening tests point of view, the truth is nobody knows if there is not some nasty unexpected side affects.

lossyWAV 1.3.0 Development Thread

Reply #133
I'm not talking about perceptual transparency. I mean transcoding quality. Artifacts from transcoding have little to do if LW is transparent or not. If LW is not transparent on a sample you may hear the same artifact on the transcode - that is not a transcoding artifact. A transcoding artifact is an extra effect added not present in the original wav or LW file .

lossyWAV 1.3.0 Development Thread

Reply #134
Surely there's no real argument here.
People who use lossywav as a lossless replacement (me for example) use a high setting so they can transcode; people who use it as a lossy replacement (Nick & halb27) will use a setting close to perceptual transparency where transcoding may be an issue, but since they're using instead of other traditional lossy codecs, they won't have the need to transcode.

As long as lossywav offers both, and presumably all this noise shaping stuff is only going to be for below a certain setting, then there's no transcode issue.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV 1.3.0 Development Thread

Reply #135
So I am not denying that the generation loss of lossywav to lossywav is likely smaller than DCT to DCT & so that lossywav to DCT is likely less agressive than DCT to DCT. What I am pointing out is that this generation loss exist even if smaller, & that using lossywav near its transparency point as a source for further DCT encoding, you're playing with your luck & risking to have both lossywav & DCT artefacts in the final encode ... with the possibility of a third artefact due to cross-transcoding randomness (Travelling unknown ground). So the theoric "transcodability" of lossywav depends on so many factors & trying to improve it is insane. Furthermore selling lossywav to newbies as a transcodable codec in all situation is not true too.

Saying that lossywav is less agressive than DCT is true, saying that lossywav is suited for transcoding is arguable because it depends on how you use lossywav & to what you're comparing it too.

A transcoding between Nero AAC 320Kbps VBR to Nero AAC 192Kbps VBR is likely to be transparent too (I dunno I never tested but I would assume so), does this make Nero AAC suited for transcoding ? I don't think so.

The supposed "transcodability" of lossywav depends on how many generation loss you're willing to suffer, & as 99% of people will not suffer more than 1 transcoding, Nero AAC 320Kbps VBR is not less suited than lossywav -q5 for transcoding if you will only do 1 additionnal transcoding. Nero 320Kbps or lossywav -q5 as the source it doesn't matter, because a single generation loss is likely to not be ABXable. (Edit: Big typo here)

What this means is that people who use lossywav only for this supposed better transcodability are fooling themselves with something like "a warm & fuzzy" audiophile feeling.

Not that they are completely wrong (With more than 1 generation loss they are probably right), but they must know the limit in real life of this theoric benefit. Once they will understand this limit they will likely understand that keeping this virtual gain shouldn't hinder lossywav normal development as a lossy codec. It isn't worth it.

Edit:
I completely agree with carpman, there seems to be two schools of lossywav users:
1:Lossless(on PC)+Lossywav(on DAP)
2:Lossywav(on PC)+Classic lossy(on DAP)
The first school seems to consider lossywav as a lossy codec of its own, the second as a lossless replacement, that's why if ever Nick dives into the realm of real lossy codecs technology, I asked for a "transcoding setting" for this kind of users, so that the two use of lossywav doesn't conflict together.

Edit2: Fixed a big typo ... & plenty of small  Sorry.

lossyWAV 1.3.0 Development Thread

Reply #136
My test with 1.2.2.k unfortunately did not show up improvements for furious. Artefacts are very audible.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #137
collector:
Sure old -q7.5 & -q5 can suffer a classic lossy generation loss without being distinguishable from pure lossless as a source, the safety margin here is large enougth. What I am saying is that I doubt that you can say the same for old -q2.5, because here there is almost no margin.

My not so old version 1.2.0 still states -E > 'high quality, also suitable for transcoding' and I do agree with that. So my lossyflac -q8 images provide a good source for my transcoded tracks, mp3 V2 (for the wife's Sansa Clip). That's it.
Transcodes are to mp3, not to lossyflac -P because the mp3's are much smaller. Artifacts ? Why bother. The Clip is used in trains, stations and other noisy environments.

Quote
For me "transcodability" is a nice side effect of the used technology of lossywav. Not a main feature.

Agreed. I mainly use -q8 for classical and -q6 for the rest, being blues rock and pop.

lossyWAV 1.3.0 Development Thread

Reply #138
.... So the theoric "transcodability" of lossywav depends on so many factors & trying to improve it is insane. Furthermore selling lossywav to newbies as a transcodable codec in all situation is not true too.

I think lossyWav isn't sold to be a transcodable codec in ALL situations. Only -I and -E (-q10 down to -q7.5) are mentioned. And I think that's right. And off course, the newbies are responsible for their own conversions, transcodings and ABXing.

I won't discuss transcoding from whatever low lossyflac setting to whatever low lossy setting here, since I don's use lower than -q6. Lower than this I think transcoding must be tested properly by a testpanel.

lossyWAV 1.3.0 Development Thread

Reply #139
The conclusion is that if your not ready to give up some bitrate for some flexibility, then you should not use lossywav.
If you think Musepack is more handy than lossywav, just use Musepack.


I'm not sure what you're disagreeing with, but if you're referring to me as the only (I think) person who has mentioned using Musepack on this page, I never intended them to compete. My point was exactly opposite, in fact!

Also I completely disagree with the theorical myth that lossywav would be suited for further transcoding with classic lossy codecs, this might be true but there is no real evidence of this. Furthermore it likely highly rely on which lossywav setting you used prior doing further transcoding. If you used lossywav near its transparency point as the first encode, I personnaly highly doubt that you can transcode it a second time with a classic lossy codec & get an as good result as if it were a first classic lossy encode. All this is very theoric & untested, but what this means to me, is that because nobody really knows how lossywav react to transcoding (except for saying very vague statements like "the higher is the quality of the source the better will be the transcoding"), optimizing it for this use is insane.



Myth? I proposed it as a goal for people who are looking at LossyWAV as a possible replacement of lossless codecs. (That's disregarding the fact that such feature is directly advertised in the settings.)

There aren't that many differences in general principles by which popular lossy codecs operate; it might be possible to account for some of them at least in regards to how they process data. In other words, not using noise-shaping/masking algorithms that are prone to introducing additional difficulties for lossy codecs, at least on switches intended for stable first-generation transparency and not portable or high-compression use.

Infrasonic Quartet + Sennheiser HD650 + Microlab Solo 2 mk3. 

lossyWAV 1.3.0 Development Thread

Reply #140
lossyWAV beta 1.2.2m attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #141
I tested 1.2.2.m with furious.
-Z --adaptive is better IMO than with the recent versions, however hiss and artefacts are pretty audible.
But I guess this setting uses a bitrate which possibly will never be fine for problematic samples so I also tried -Z --adaptive --altpreset.
Result is good. I can't hear an artefact. Within second 1.8 to 2.7 I think I can hear a tiny amount of hiss, but ABXing lead only to 7/10.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #142
Thanks for the v.fast response (and taking the trouble to ABX yet again  ) - I was beginning to think that Furious may never be transparent at -Z -A - your results give some support to that opinion. Taking into account that -Z -A -t will result in fewer bits-removed than -Z -A, (333kbps resultant FLAC rather than 266kbps, in this case) as it is roughly equivalent to -q 1.685 -A --limit 15159, it would be interesting to know your opinion of Furious at -q 1.5 -A.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #143
I just tested furious using 1.2.2m -q 1.5 -A.
I could ABX the hiss in the 1.8...2.7 second range 10/10, and it wasn't very hard.
For a comparison I retested the same sample snippet using -Z -A -t as I did yesterday. Today I arrived at 9/10, so the hiss is audible too. ABXing was harder though than when using -q 1.5 -A.
Once about to compare I also tested the snippet using -Z -t. I couldn't ABX the hiss I heard using -A.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #144
Thanks again - I'll focus on that region of the sample and compare the output of -Z -t with -Z -A -t.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #145
For anybody wishing to experiment with the current implementation of adaptive noise shaping, there are three hidden parameters for --adaptive:

<filter_length> : 16<=n<=256; default=32;
<warp_lambda> : 0<=n<=0.7; default=1/3;
<persistence> : 0<=n<=1; default=0.1;

Examples:

--adaptive 64 : filter_length=64;
--adaptive x 0.5 : filter_length=default; warp_lambda=0.5;
--adaptive x x 0.2 : filter_length=default; warp_lambda=default; persistence=0.2.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #146
<filter_length> : 16<=n<=256; default=32;
<warp_lambda> : 0<=n<=0.7; default=1/3;
<persistence> : 0<=n<=1; default=0.1;

What exactly each of them affects?

lossyWAV 1.3.0 Development Thread

Reply #147
Filter_length : bigger is better (more accurate), but slower;
Warp_lambda : bigger = more emphasis on accuracy for lower frequencies;
Persistence : 1 = only use spectrogram from this codec-block; 0.5 = use half from previous codec_blocks and half from this codec_block; etc.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #148
Persistence : 1 = only use spectrogram from this codec-block; 0.5 = use half from previous codec_blocks and half from this codec_block; etc.

Haven't you gotten that backwards? If 1 means use only spectrogram from this codec block, that means the default setting of 0.1 takes into account the current spectrogram with weight 1/10 and the previous spectrogram with weight 9/10.

lossyWAV 1.3.0 Development Thread

Reply #149
The present value of the persistence parameter is an attempt to smooth out the desired shape.

lossyWAV beta 1.2.2n attached to post #1 in this thread.

[edit] lossyWAV beta 1.2.2p attached to post #1 in this thread. [/edit]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)