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: Intrinsic transcoding with LossyWAV (Read 4047 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Intrinsic transcoding with LossyWAV

I'd like to establish a quasi-"lossless" archive with LossyWAV --standard or --extreme when 1.2.0 stable gets released. From that I'd transcode to --portable for my, well, portable. I did a quick transcoding-test with some mono files. Here are the bitrates I got:
Code: [Select]
Lossless (0)            -> LossyWAV --standard (1) = 247 kbps
LossyWAV --standard (1) -> LossyWAV --standard (2) = 241 kbps
LossyWAV --standard (2) -> LossyWAV --standard (3) = 241 kbps

So the first transcode from --standard to --standard decreases bitrate by 6 kbps, while further transcodes don't lower the bitrate anymore. Now I wonder what cumulative effect is causing the drop in first transcode pass (and only there?) and how much the quality level will possibly drop when transcoding from, say --standard to --portable compared to native --portable from lossless.

Intrinsic transcoding with LossyWAV

Reply #1 –
I don't know how noise shaping affects this, but certainly without noise shaping, it works like this:

It's possible to hit a point where transcoding lossyWAV > lossyWAV does exactly nothing - i.e. it decides it will keep (at least) the same number of bits as the previous encoding - and so all it does is zero LSBs that were already zero from the previous encoding - and hence the transcoding stage is lossless!

This isn't guaranteed to happen - it's just that it can happen.

Where it doesn't happen (i.e. where there's a change), something different occurs: lossyWAV (1) sets some LSBs to zero. This can be interpreted as adding noise, and so the next stage of lossyWAV (2) sees more noise at the analysis stage, thinks more bits can be set to zero, and does this.


If you edit the file between transcoding (e.g. cut a little silence from the start), the block boundaries of the different lossyWAV passes won't line up, so it won't work so predictably.

Cheers,
David.