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 and the don't transcode lossy to lossy rule (Read 13740 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV and the don't transcode lossy to lossy rule

Hi all,

I'm trying to explain why transcoding from lossyWAV (a variable bit-depth non-transform lossy pre-processor, but for simplicity's sake a lossy encoder) to a lossy (transform codec) such as LAME MP3, kind of breaks the "don't transcode lossy to lossy" rule (here I'm assuming a defensive lossyWAV setting such as --standard). However, I keep hitting a wall (i.e. my lack of technical understanding).

Can someone explain why this is (or perhaps isn't) the case?

For example, if we had a lossy transform codec with an avg variable bitrate in the 450 kbps range, would that be any more likely to introduce artifacts than a lossyWAV --standard encode at the same bitrate when transcoded to say LAME at -V 2?

Any help or useful links welcome.

Finally, as far as I know a major lossyWAV transcode test hasn't happened yet, are there any plans? I realise Nick et al are pushing the limits with the lower settings, but it would be interesting to find the lowest safe transcode settings too.

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #2 –
Thanks for the link - interesting thread. What seems pretty clear is that transcoding from lossyWAV --standard > LAME -V 5 and up is going to be fine. Though I'm still none the wiser as to whether this is purely a bitrate issue or due to the nature of the lossy encoder.

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #3 –
Part of the issue is simply that LossyWAV tends to target a far, far higher quality profile than many lossy codecs. If we all used Vorbis or AAC at 600kbps, one would have to imagine that proscriptions against transcoding would not happen nearly as much.

That said, LossyWAV manipulates the signal in the time domain while most lossy codecs operate in the frequency domain. And LossyWAV explicitly tries to avoid making significant changes to the spectrum. So one could argue that there is some degree of orthogonality to the two approaches - while repeated MP3 transcoding will cause artifacts that will tend to multiply on top of one another, an MP3 encode may not affect the artifacts produced by LossyWAV one way or another.

That's the idea, anyway, AFAIK.

lossyWAV and the don't transcode lossy to lossy rule

Reply #4 –
Guruboolez once did a transcode test of various lossy codecs at 256 kbps to Lame mp3 -V5.
Main result was that transcoding mp3 to mp3 was bad, but there was no issue transcoding from Vorbis and other high quality codecs this way.
The codec most similar to lossyWAV that participated was wavPack lossy, and the transcoding results were good though not as good as those of Vorbis (256 kbps is a rather inadequate bitrate for wavPack lossy as was remarked by Guruboolez).

When transcoding from a high quality lossy codec used with very high bitrate to another lossy codec of significantly lower bitrate we can expect that overall quality is dominated by the quality of the target codec. Maybe lossyWAV has special merits here due to its different principle.

I think there is nothing to worry about when transcoding say lossyWAV --standard to Lame -V0.
But the same will be true when replacing lossyWAV --standard by a good AAC encoder at 450 kbps (AAC as an example).
I personally would prefer lossyWAV however.
lame3995o -Q1.7 --lowpass 17

lossyWAV and the don't transcode lossy to lossy rule

Reply #5 –
I would think about testing the results of disabling noise shaping in lossyWAV if you intend to transcode to mp3.

The benefits of noise shaping may, or may not, be outweighed by mp3's "strange" behaviour above 16kHz.

Cheers,
David.

lossyWAV and the don't transcode lossy to lossy rule

Reply #6 –
Quote from: halb27 on
But the same will be true when replacing lossyWAV --standard by a good AAC encoder at 450 kbps (AAC as an example).
I personally would prefer lossyWAV however.

Is this for the reasons Axon outlined?

Quote
That said, LossyWAV manipulates the signal in the time domain while most lossy codecs operate in the frequency domain. And LossyWAV explicitly tries to avoid making significant changes to the spectrum. So one could argue that there is some degree of orthogonality to the two approaches - while repeated MP3 transcoding will cause artifacts that will tend to multiply on top of one another, an MP3 encode may not affect the artifacts produced by LossyWAV one way or another.


Quote from: 2Bdecided on
I would think about testing the results of disabling noise shaping in lossyWAV if you intend to transcode to mp3.
The benefits of noise shaping may, or may not, be outweighed by mp3's "strange" behaviour above 16kHz.

Can you elaborate on this? A worst case scenario example would be very handy. Won't noise shaping push the added noise further into the range where a lossy codec would dismiss it as inaudible and thus completely filter it out?

Thanks for the informative replies,

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #7 –
Quote from: carpman on
Quote from: halb27 on
But the same will be true when replacing lossyWAV --standard by a good AAC encoder at 450 kbps (AAC as an example).
I personally would prefer lossyWAV however.

Is this for the reasons Axon outlined?

Yes.

But may I ask what is the practical background for your question?
Do you like to use lossyWAV --standard, but you also have a mobile DAP with restricted memory so that you want to transcode (to exactly what?).
Knowing exactly your needs can help to give the most appropriate  answers.

As for noiseshaping when transcoding: nooiseshaping brings more noise into the 13+ kHz region. There's a good chance that the lossy target codec will try to approximate the noise which is inefficient, especially in the case of mp3 as mo3 treats the 16+ kHz region in a specific way that can be very inefficient on occasion.

Oops: I just saw that the link lvqcl gave is exactly Guruboolez test I mentioned.
lame3995o -Q1.7 --lowpass 17

lossyWAV and the don't transcode lossy to lossy rule

Reply #8 –
Quote from: halb27 on
Yes.

But may I ask what is the practical background for your question?
Do you like to use lossyWAV --standard, but you also have a mobile DAP with restricted memory so that you want to transcode (to exactly what?).
Knowing exactly your needs can help to give the most appropriate  answers.

Sure, I'm writing some copy for recommended lossless / lossy PC/DAP etc. encoding options. 
The recommendation is as follows (at present):
- Pure lossless archive (as backup)
- LossyTAK as resident PC audio collection (thus this would be the main transcode source) - and thus the question becomes how far do you push this ( --standard, -q 4, -q 3 ?) where does lossyWAV stop becoming a viable transcode option?
- LAME -V 2, -V 3 (for DAP).

So I was just checking the transcode issue before writing up the recommendation. This isn't for a highly technical audience, but not a dumb one either, so I wanted to explain why lossyWAV at x bitrate would be better than a transform codec of the same bitrate, but that was the assumption that I wanted to check prior to writing.

Hope that helps.

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #9 –
Hm, it's all a question of personal taste, but isn't a 3 level approach a bit much?
When adding to the collection it means keeping up to date all the 3 levels.

With today's storage capacities on PCs isn't it possible to use pure lossless for the resident pc usage and archiving?

IMO the main advantage of lossyWAV is to have an extremely high quality lossy codec that can be used on PC and with many mobile DAPs (those that support FLAC and have a decent amount of storage space). With restricted space on mobile DAPs you can use a mixture of lossyWAV/FLAC tracks (for the best of your music) and codecs like mp3. That's what I do.

Back to your question: With Lame -V2 in mind as the target I wouldn't care a bit using lossyWAV --standard as the source. I wouldn't care using even --portable.
IMO all the eventual audible deviation from the original can be contributed to the small degree of imperfection of -V2.
You won't get a proof however.
lame3995o -Q1.7 --lowpass 17

lossyWAV and the don't transcode lossy to lossy rule

Reply #10 –
I agree it's a matter of taste and circumstances.
Perhaps I'll make a 2 level recommendation:

1) Where space is no issue and compatibility is:
There I'll suggest FLAC -5 pure lossless with compatibility for all sorts of home networked devices etc .. and transcode to MP3 for DAP when requied.
2) Where space is a concern and compatability isn't:
There I'll suggest the prior recommendation (to me it's a 2 tier approach - as you're not necessarily maintaining an MP3 library for DAP - just transcoding when necessary - but again that's to do with personal preferences and second guessing how people use their DAPs is tricky).

I do find it funny however, when this issue comes up, about space. If one follows it through it's hard to justify the point of TAK or WavPack since their advantage over FLAC is miniscule (2% here and there) compared to the gains of LossyWAV which cuts the size by half again.

Personally, I can afford to leave all the lights on in my house, but when I leave a room I turn the lights off, why? I guess that's how I feel about HDD space, sure it's cheap and I could use lossless to fill it, but it seems unnecessary. I'm not quite sure why, to be honest.

Anyway, thanks for the input halb27, always thought provoking and I think I will make those 2 recommendations instead of just the one.

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #11 –
Quote from: carpman on
.. I guess that's how I feel about HDD space, sure it's cheap and I could use lossless to fill it, but it seems unnecessary. ...

Yes, that's true. But focussing on this you can even substitute lossless by lossyWAV --standard or --extreme according to your likings.
Risks are next to nothing.

Anyway, a 2 level approach of whatever kind wastes less storage capacity than a 3 level approach in the overall view, and maintenance
is a lot easier.
lame3995o -Q1.7 --lowpass 17

lossyWAV and the don't transcode lossy to lossy rule

Reply #12 –
If only everything let you tag .wav files we could just use those everywhere and be done with it - no encoding to worry about!

Cheers,
David.

lossyWAV and the don't transcode lossy to lossy rule

Reply #13 –
Quote from: halb27 on
Anyway, a 2 level approach of whatever kind wastes less storage capacity than a 3 level approach in the overall view, and maintenance is a lot easier.

I don't think I agree.

Let's say that you have 3 locations:

1) Backup solution (DVD, external drive, 2nd HDD whatever)
2) PC Library
3) DAP

If you have pure lossless, you have same lossless files copied to the 3 locations.
If you have lossless backup, lossyWAV for PC and MP3 for DAP you have 3 different encodes in 3 locations (so sure there are more encoding hassles), but each time it's a 3 level approach, no?

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #14 –
Quote from: carpman on
Finally, as far as I know a major lossyWAV transcode test hasn't happened yet, are there any plans? I realise Nick et al are pushing the limits with the lower settings, but it would be interesting to find the lowest safe transcode settings too.

A year ago, I did a personal transcoding test on v1.1.0b -portable:
http://www.hydrogenaudio.org/forums/index....showtopic=65637

I'd like to see other results too, and try another round.

Quote
I guess that's how I feel about HDD space, sure it's cheap and I could use lossless to fill it, but it seems unnecessary. I'm not quite sure why, to be honest.

That's my interest in LossyWAV too. I don't need everything in lossless, that would be too unnecessary for me. Like Halb27 says, it's not to my taste  I only need lossless for things I personally recorded or I own the master/only copy of. For everything else Lossywav is certainly good enough. Especially after looking at failed transcoding abx results 

lossyWAV and the don't transcode lossy to lossy rule

Reply #15 –
Quote from: carpman on
....
Let's say that you have 3 locations:

1) Backup solution (DVD, external drive, 2nd HDD whatever)
2) PC Library
3) DAP

...

Talking about backup extends thinking towards backup strategy.
I personally backup any data of any kind I have on my internal PC HD to external HD.
Thinking like this about backup doesn't allow for giving a lossless encoding the meaning of a 'backup',
it rather has the meaning of a safe-haven version of the collection within a multi-level approach (which
should reside not only on the backup medium cause otherwise there were no backup copy of the lossless
version).
With this kind of thinking about backups a 3 level strategy takes more amount of diskspace than
when skipping the best or intermediate level.
lame3995o -Q1.7 --lowpass 17

lossyWAV and the don't transcode lossy to lossy rule

Reply #16 –
Ah, good point. I guess I'd never thought of it like that as I regard the lossless files as a tagged backup of the CD, so worst case if my lossless non-"backup" fails (DVD) I can re-rip and "copy info from files" from the lossyWAV, so it's not a big deal. But that's a good point. I'm glad I held back on writing this up. Anyway, backup strategies are another topic, but some food for thought.

Thanks again for the input.

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

lossyWAV and the don't transcode lossy to lossy rule

Reply #17 –
AFAIK the reasons why LossyWAV is generally considered "safe" for transcoding purposes are
1) it does no waveband transformation,
2) it utilizes no psychoaccoustics.
This simple approach avoids most possible causes for transcoding artefacts, resulting from conflicting psy-models etc.

lossyWAV and the don't transcode lossy to lossy rule

Reply #18 –
Thanks to Halb27, Northpack and others.
For those interested, the conclusions made their way here. As was clear in this thread everyone has their way of doing things; this info is a) there to provide an indication of the options available, and b) aimed at a non-technical, lay but intelligent audience.

What may be of some interest is the "LossyWAV v. Lossless v. by type of music" mini-test (small sample set, but indicative):



Cheers,

C.

ps. Keeping an eye on Northpack's LossyWAV to LossyWAV transcode test.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV and the don't transcode lossy to lossy rule

Reply #19 –
I'm amused that mp3 had such a good compression ratio for white noise. One might guess that it would be difficult to encode so many (infinite) frequencies, but I suppose if mp3 does a very poor job of encoding, the result is the addition of lots of noise.

So the resultant signal may bear little resemblance to the original as far as reproducing the actual waveform, but to the extent that all white noise sounds the same, it has done its job.

lossyWAV and the don't transcode lossy to lossy rule

Reply #20 –
Very nice graph.

I'm surprised lossyTAK did so poorly with the white noise. It certainly can be as efficient with white noise as with over compressed pop music. Severe band limiting could get in the way, as could severe clipping. Maybe Nick has some insight?

Also, I'm surprised FLAC scored exactly 100% with white noise. It can usually squeeze something out! Maybe your noise generator is better than mine!

Cheers,
David.

lossyWAV and the don't transcode lossy to lossy rule

Reply #21 –
David,

Looking at dither_noise_test.flac that you provided some time ago, lossyWAV --standard removes an average of 9.6 bits per sample produces output which compressed using FLAC results in a lossy.FLAC file 78.6kiB from 172.2kiB of WAV (45.6% of uncompressed size). Unprocessed FLAC size is 180.4kiB (104.8%)

[edit] The same lossyWAV file in TAK is compressed to 72.6kiB using TAK -p2m (42.1%). Unprocessed TAK file size is 172.9kiB (100.4%)[/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)
 

lossyWAV and the don't transcode lossy to lossy rule

Reply #22 –
Quote from: 2Bdecided on
Also, I'm surprised FLAC scored exactly 100% with white noise. It can usually squeeze something out! Maybe your noise generator is better than mine!

FLAC did squeeze some bits -- it looks like 100% but it's not exactly (so perhaps not such a nice graph  )
Here's the bitrates:



FLAC = 1407 kbps on white noise. ps. I think you use Cool Edit and that's what I used to generate the white noise, with intensity set to 40 (max).

Yes, I wondered about LossyWAV on white noise, not that it's important, but plenty of noise in which to hide added noise?

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