IPB

Welcome Guest ( Log In | Register )

16 Pages V  « < 4 5 6 7 8 > »   
Closed TopicStart new topic
lossyWAV 1.3.0 Development Thread, Added noise WAV bitdepth reduction method.
SebastianG
post Jun 11 2010, 13:35
Post #126





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (sauvage78 @ Jun 11 2010, 12:59) *
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")

QUOTE (sauvage78 @ Jun 11 2010, 12:59) *
This means that transparency & bitrate is not everything in audio.

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

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.

QUOTE (sauvage78 @ Jun 11 2010, 12:59) *
[…]
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. smile.gif

Cheers!
SG

This post has been edited by SebastianG: Jun 11 2010, 13:42
Go to the top of the page
+Quote Post
Nick.C
post Jun 11 2010, 22:06
Post #127


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
doccolinni
post Jun 11 2010, 22:36
Post #128





Group: Members
Posts: 172
Joined: 28-May 09
From: Zagreb, Croatia
Member No.: 70204



QUOTE (Nick.C @ Jun 11 2010, 23:06) *
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.
Go to the top of the page
+Quote Post
doccolinni
post Jun 11 2010, 23:56
Post #129





Group: Members
Posts: 172
Joined: 28-May 09
From: Zagreb, Croatia
Member No.: 70204



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. wink.gif
Go to the top of the page
+Quote Post
collector
post Jun 12 2010, 10:46
Post #130





Group: Members
Posts: 220
Joined: 2-July 04
Member No.: 15029



QUOTE (sauvage78 @ Jun 11 2010, 03:59) *
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).
Go to the top of the page
+Quote Post
sauvage78
post Jun 12 2010, 11:54
Post #131





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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.

This post has been edited by sauvage78: Jun 12 2010, 12:06


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
shadowking
post Jun 12 2010, 12:37
Post #132





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



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.

This post has been edited by shadowking: Jun 12 2010, 12:40


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
sauvage78
post Jun 12 2010, 13:59
Post #133





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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.

This post has been edited by sauvage78: Jun 12 2010, 14:43


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
shadowking
post Jun 12 2010, 15:21
Post #134





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



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 .


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
carpman
post Jun 12 2010, 15:42
Post #135





Group: Developer
Posts: 1310
Joined: 27-June 07
Member No.: 44789



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.


--------------------
TAK -p4m :: LossyWAV -q 6 | TAK :: Lame 3.98 -V 2
Go to the top of the page
+Quote Post
sauvage78
post Jun 12 2010, 15:58
Post #136





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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 wink.gif Sorry.

This post has been edited by sauvage78: Jun 12 2010, 16:15


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
halb27
post Jun 14 2010, 11:09
Post #137





Group: Members
Posts: 2433
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



My test with 1.2.2.k unfortunately did not show up improvements for furious. Artefacts are very audible.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
collector
post Jun 14 2010, 13:20
Post #138





Group: Members
Posts: 220
Joined: 2-July 04
Member No.: 15029



QUOTE (sauvage78 @ Jun 12 2010, 02:54) *
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.
Go to the top of the page
+Quote Post
collector
post Jun 14 2010, 13:41
Post #139





Group: Members
Posts: 220
Joined: 2-July 04
Member No.: 15029



QUOTE (sauvage78 @ Jun 12 2010, 06:58) *
.... 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. wink.gif

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.
Go to the top of the page
+Quote Post
moozooh
post Jun 16 2010, 20:50
Post #140





Group: Members
Posts: 357
Joined: 22-September 04
From: Moscow
Member No.: 17192



QUOTE (sauvage78 @ Jun 11 2010, 15:59) *
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!

QUOTE (sauvage78 @ Jun 11 2010, 15:59) *
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. 
Go to the top of the page
+Quote Post
Nick.C
post Jun 17 2010, 20:53
Post #141


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Jun 17 2010, 21:26
Post #142





Group: Members
Posts: 2433
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Jun 17 2010, 21:26


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Jun 17 2010, 21:49
Post #143


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



Thanks for the v.fast response (and taking the trouble to ABX yet again smile.gif ) - 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.

This post has been edited by Nick.C: Jun 18 2010, 19:41


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Jun 18 2010, 21:36
Post #144





Group: Members
Posts: 2433
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Jun 18 2010, 21:37


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Jun 18 2010, 22:08
Post #145


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Jun 20 2010, 21:03
Post #146


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
doccolinni
post Jun 20 2010, 21:59
Post #147





Group: Members
Posts: 172
Joined: 28-May 09
From: Zagreb, Croatia
Member No.: 70204



QUOTE (Nick.C @ Jun 20 2010, 22:03) *
<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?
Go to the top of the page
+Quote Post
Nick.C
post Jun 20 2010, 22:09
Post #148


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
doccolinni
post Jun 20 2010, 23:30
Post #149





Group: Members
Posts: 172
Joined: 28-May 09
From: Zagreb, Croatia
Member No.: 70204



QUOTE (Nick.C @ Jun 20 2010, 23:09) *
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.
Go to the top of the page
+Quote Post
Nick.C
post Jun 21 2010, 13:00
Post #150


lossyWAV Developer


Group: Developer
Posts: 1790
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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]

This post has been edited by Nick.C: Jun 21 2010, 18:48


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post

16 Pages V  « < 4 5 6 7 8 > » 
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: 2nd September 2014 - 10:11