lossyWAV 1.3.0 Development Thread
Reply #139 – 2010-06-16 20:50:54
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.