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: Using lossyWAV for an "open MQA" ? (Read 8433 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Using lossyWAV for an "open MQA" ?

With all those bits zeroed by lossyWAV, can we think of a way to properly down-sample an audio file and encode as much lost information as possible in those least significant bits (LSB)? To my understanding, this would be like an "open MQA" audio process.  8)

I also wonder if this would double the amount of noise, and if we would have to take into account the compressed information (in LSB) in the noise shaping algorithm. Hmm...  :-\

And that brings me to the question: does the world need an "open MQA" format?

Re: Using lossyWAV for an "open MQA" ?

Reply #1
Sure, maybe you could create an audibly transparent 32kHz 16-bit file by "folding" the higher frequencies of a 44.1kHz file into the lower bits, similar to what MQA is doing.
It probably wouldn't work for all audio content, but it could work for a lot of dynamically compressed music.

But in the end, what would you really gain from it?
Would you get lower bitrate compared to something like AAC or Opus, which can be just as audibly transparent? I don't think so. And some content with a lot of dynamic range or HF content could still suffer from audible degradation.
So it seems rather pointless.

Just like MQA itself is pointless in terms of reducing bitrate for "high res" music, when you consider the fact that you can already zero out the useless LSBs and remove the useless ultrasonic content. You could create, for example, 60kHz 18-bit audio, packed into a 96kHz 24-bit FLAC (just for compatibility). Assuming that anything more than 44.1/16 even has any benefits, of course, otherwise you could go lower instead.

Re: Using lossyWAV for an "open MQA" ?

Reply #2
And that brings me to the question: does the world need an "open MQA" format?
That is the easiest part of it to answer. As Brand points out, you could just go to a format that supports the information itself.

Disregard the marketing bullshit and concealed DRM: essentially what HDCD and MQA attempted at, was to use some of the bits to store information the format didn't really provide for, and so that unaware players would still get something playable. HDCD would essentially hide a volume control in the dither, and a HDCD-unaware DAC would skip these volume adjustments (and for example get a slightly different fade-out effect).

If you are still in it just for the fun of keeping the constraint and seeing what you can make out if it: well, you could just downconvert to 14 bits (no dithering), with "HDCD packet"-alike flags to instruct the decoder to do something else with the last two bits.
* 14 bits is pretty good even if the rest is noise, it provides for a dynamic range of 84 dB (disregarding dithering), and early consumer DACs were no better.
* 2 bits for the rest: Two bits at 44.1 kHz amounts to a bitrate of 176.4 bits/second, enough to give you a damn good lossy representation for the entire signal. Here you don't encode the entire signal, only the difference to the 14, lowpassed at whatever you want (say 32 kHz if that is what your marketing department fancies).

You don't need to do it clear-cut 14+2: The packet flag could tell you to roll back the lossy part to 1 bit per sample = 88.2 bits/second in quiet parts (when the music is so low that you want the noise floor at -90 rather than at -84). This was a very naive way of doing it; you could upon encoding scale the lossy part down by fractions of a bit too, to use it as dither in the 15th (and even the 16th) bit.

Now, did I just even describe MQA? Who knows.

Re: Using lossyWAV for an "open MQA" ?

Reply #3
Don't know it is a good idea to create a format that makes sense against an audiofool licencing project.
You have no chance against the authentic blue and green light that authenticates the unauthenticable.
People look at their DACs and see MQA plays back at huge sampling rates and unfold followed by unfold packed in magic wording makes them think it is the full original file and better while it is only a lousy upsampling trick.
MQA lovers are often intentionaly misinformed over the so called classic audio magazines and fora. Also a horde of influencers pestilated many places with fake news.
Really want to compete with that?
Lets face it. 16/44.1 is all you ever need on almost everything. If you are desperate keep it at 24/96 and even that should be easy stremable today.
Lets hope MQA dies in misery.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Using lossyWAV for an "open MQA" ?

Reply #4
Thank you all for your answers.

I forgot to mention that I was mostly thinking about hi-resolution audio applications. Of course, FLAC, AAC and Opus would be my preferred choices for any 44.1/48kHz-16bits contents, but I was instead looking for an open lossy codec for higher resolution files. As some of you have pointed out, 96kHz data is not absolutely necessary, but if we have it, then any lossy version of it should be just perfect in terms of quality/file_size.

Given that FLAC has an expected compression ratio of 50% (±20%), then what would we get if we instead keep as much audio information as possible with a fixed relatively high bit-stream bandwidth? In other words, what can we get with 1.5Mbps? For example, can we ensure to have at least a lossless representation of 44.1kHz/16-bit data, plus extra information for up-sampling?

I did a few tests with a 2L audio test file (DIVERTIMENTI - Trondheimsolistene, Stereo 24BIT/192kHz):
- Original uncompressed WAV file: 209MB
- Firstly, I have changed the WAV header to 48kHz in order to fake that sample-rate for Opus (which is designed for 48kHz at most). After the Opus compression: 24MB (8.5x smaller)
- Secondly, from the original WAV file back to 192kHz, and after lossyWAV + FLAC: 31MB (6.7x smaller)

Going from 192/24 raw bit-rate (~9Mbps) to 48/16 raw bit-rate (~1.5Mpbs), the later is 6x smaller. Therefore, it appears that lossyWAV+FLAC already meet the requirement, that is 1.5Mbps can provide a quite good approximation of a 192/24 audio file. Regarding the compression with Opus (with a fake 48kHz sample-rate), there was a clear difference in highly dynamic portions of the song; maybe it still sounded good, but lossyWAV just gave a better result (at least, on graphics).

From these results, it looks like adding information in lossyWAV-zeroed LSBs is no longer necessary. But if we still think about it... with 192kHz files, a 4x sample-rate reduction could compensate for the additional information in the LSBs (to be determined). But with 96kHz files, a 2x sample-rate reduction does not seem to be enough of a saving if we then add more information in the LSBs (to be determined).

Consequently, 96kHz files + lossyWAV(from standard to insane modes) + FLAC is probably what I am looking for. I will do more tests.  :)

Re: Using lossyWAV for an "open MQA" ?

Reply #5
First: Are you doing this for the sport, or for usefulness? If it is for the game of it, then feel free to do whatever you think might be fun.

For example, to answer the question of what you can fit in 1500 kbit/s, you might take a LossyWAV implementation that peels off one bit by one bit until FLAC brings you down to 1500. (Well what does that mean? Quoted bitrate for FLAC is per file, and if you want it to be streamable constrained by such a bandwidth bottleneck, you might want to constrain it to be no more than 1500 (plus small buffer) measured over any very short timespan, not per file.)
Given that the extra octave is expensive, you might want to lowpass your 96/24 as well, and make a model that trades off the frequency against the number of effective bits. Like, for a given tough signal, lowpass at 28 and 18 effective bits.

Re: Using lossyWAV for an "open MQA" ?

Reply #6
We are still talking about MQA equivalence? MQA at a maximum atm carries 17-18bit and 48kHz bandwith. The rest is fake from very bad upsampling and filling the lower bits with noise on decrypting.
Very early in the analysis of MQA they already found a simply noise shaped bit reduced standard 24bit 96kHz file compresses better with flac while keeping more original information.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Using lossyWAV for an "open MQA" ?

Reply #7
At the moment, any development would be for the sport of it, since I am not 100% sure this would be useful. But, who knows...

Yeah, the 1500 kbps is almost arbitrary (but based on 48/16 bit-rate), and can be set either as a constant bit-rate (over short time periods) or as an average bit-rate; both cases are interesting to explore. The cited song is also probably easier to compress than other songs, which means I cannot generalize on a single test file.

Applying a low-pass filter on the 96/24 data sounds fair, but I am not sure why 28kHz; I would have picked 30kHz.

If MQA is that bad, there may be a better solution to be found. :-)

Re: Using lossyWAV for an "open MQA" ?

Reply #8
If MQA is that bad, there may be a better solution to be found. :-)

Better solution to me is compress the original 96/24 file as is and be done with it.  Resampling and dithering to 44.1/16 on playback is very easy to do correctly without introducing any artifacts.  If a system natively supports 96/24, play as is.

Re: Using lossyWAV for an "open MQA" ?

Reply #9
Yeah, I agree. With my dataset:

- Original WAV 96kHz/24bit: 4608 Kbps
- Original FLAC file: 2095 Kbps (average)
- lossyWAV(I)+FLAC: 1062 Kbps (average)
- lossyWAV(E)+FLAC: 899 Kbps (average)
- lossyWAV(H)+FLAC: 769 Kbps (average)
- lossyWAV(S)+FLAC: 712 Kbps (average)

The lossyWAV insane mode just does the trick to allow 1Mbps (average) FLAC files. At 2Mbps (average), original FLAC files are still affordable on regular high speed internet connections. Therefore, I do not see the need for MQA for 96kHz/24bit files.

Thanks.

Re: Using lossyWAV for an "open MQA" ?

Reply #10
Very early in the analysis of MQA they already found a simply noise shaped bit reduced standard 24bit 96kHz file compresses better with flac while keeping more original information.
Not unexpected, but ... source?

Re: Using lossyWAV for an "open MQA" ?

Reply #11
This was inside some huge threads and analysis were done by mansr and miska maybe Archimago also. I can't find it easily.
AFAIK an 18-96 file already was at similar size with standard dither and not even noise shaped.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Using lossyWAV for an "open MQA" ?

Reply #12
This was inside some huge threads and analysis were done by mansr and miska maybe Archimago also. I can't find it easily.
AFAIK an 18-96 file already was at similar size with standard dither and not even noise shaped.
I participated in that thread so I still remember some of the posts.
https://www.audiosciencereview.com/forum/index.php?threads/mqa-deep-dive-i-published-music-on-tidal-to-test-mqa.22549/post-808088

The files were provided by GoldenOne and can be downloaded in this post:
https://www.audiosciencereview.com/forum/index.php?threads/mqa-deep-dive-i-published-music-on-tidal-to-test-mqa.22549/

I also mentioned I found a suspicious DXD file in 2L's website, even without MQA manipulation:
https://www.audiosciencereview.com/forum/index.php?threads/mqa-deep-dive-i-published-music-on-tidal-to-test-mqa.22549/post-803466

mansr was thread-banned but he still attempted to ask other unbanned members to continue the discussion, he reacted to my post and posted the decoded MQA version of the DXD file I mentioned. You can see that the spectrum above 35kHz or so is completely different.
https://www.audiosciencereview.com/forum/index.php?threads/mqa-deep-dive-i-published-music-on-tidal-to-test-mqa.22549/post-803904

Re: Using lossyWAV for an "open MQA" ?

Reply #13
- Firstly, I have changed the WAV header to 48kHz in order to fake that sample-rate for Opus (which is designed for 48kHz at most). After the Opus compression: 24MB (8.5x smaller)
Is there a difference in fake frequency and resampling for Opus?  :o

Re: Using lossyWAV for an "open MQA" ?

Reply #14
There is a big difference. Opus, and its CELT part in particular, assumes an internal sampling rate of 48 kHz in the frequency-dependent bit allocation process. If you relabel the 96-kHz PCM input to CELT as being 48 kHz and then relabel the decoded output as being 96 kHz, you most likely get suboptimal audio quality.

With all this MQA discussion I seriously wonder why people don't use solution which is known for more than 20 years: the dual-rate Spectral Band Replication (SBR) known from (x)HE-AAC. That encodes the high frequencies with very few bits, then downsamples the audio to half the sampling rate (in our case from 96 to 48 kHz) and, during decoding, reconstructs the 96 kHz from the 48-kHz PCM (or FLAC or whatever you encode the lower spectral half with) and the SBR data. If you want to play just the 48-kHz signal, then you can just disregard the SBR data. And the SBR data could easily be hidden in the LSB of the 48-kHz PCM, i.e., in the 16th or 24th bit.

Very simple and, as I mentioned, more than 20 year-old technology. None of the - diplomatically speaking - questionable technology which makes up MQA.

Chris
If I don't reply to your reply, it means I agree with you.

Re: Using lossyWAV for an "open MQA" ?

Reply #15
Spectral Band Replication is still patented by the MPEG patent portfolio.

Re: Using lossyWAV for an "open MQA" ?

Reply #16
Why not LossyWav+TAK?


Re: Using lossyWAV for an "open MQA" ?

Reply #18
How does it not matter? TAK compresses more efficiently! It is more profitable to create an open MQA.

Re: Using lossyWAV for an "open MQA" ?

Reply #19
How does it not matter? TAK compresses more efficiently! It is more profitable to create an open MQA.
The question was whether one could use a particular way to decimate to lower bit-depth, to free up storage for more signals.
Not about which way one should compress it later - that would be a different question.


It is more profitable to create an open MQA.
And that is an even third question, pretty much unrelated to both compression and to the LossyWAV algorithm.

(And the answer to that is most likely negative - who would want that mumbo-jumbo if it were openly specified?)

Re: Using lossyWAV for an "open MQA" ?

Reply #20
It is more profitable to create an open MQA.
And that is an even third question, pretty much unrelated to both compression and to the LossyWAV algorithm.
TAK is not related to compression, but Flaс is related.
Everything is fine. The author of the topic is trying to come up with a way to cram a maximum of bits into a 1.5Mbit stream - I suggested one of the ways. I will look further at attempts to compress > decompress high frequencies.

Re: Using lossyWAV for an "open MQA" ?

Reply #21
Since you mentioned TAK, let's not forget that the only known compressor implementation is closed source Delphi code, with assembly code mixed into it, only available for x86 architecture.

Re: Using lossyWAV for an "open MQA" ?

Reply #22
Spectral Band Replication is still patented by the MPEG patent portfolio.
Aside or maybe not ... how to read expiry out of patents.google.com? As a complete layman with English only as second language, I would have guessed that "Expired" means ... well, expired, but:
reading https://patents.google.com/patent/US7283955B2/en and https://patents.google.com/patent/EP1367566A3 and https://patents.google.com/patent/JP4220461B2/en they all say "Expired - Lifetime", yet the JP stipulates a future date for anticipated expiration.

Anyone?

Re: Using lossyWAV for an "open MQA" ?

Reply #23
Oh, oops. Guess we can use that tech now.

Re: Using lossyWAV for an "open MQA" ?

Reply #24
Related: Patent for Parametric Stereo: https://patents.google.com/patent/US8385556B1

It says: "Status: Expired - Fee Related"
and: "2031-11-09: Adjusted expiration"

So, which one is it?