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: about: AAC, Liquifier pro, mp3 etc. (Read 6311 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

about: AAC, Liquifier pro, mp3 etc.

Hi, my first thread:

1. To those who have compared: Is Liquid-audio aac still better than Psytel aac? And if it isn't, will Psytel ever be better?

2. Is there difference between the aac quality from lqt-files produced with Liquifier Pro beta2 24, Liquid Auio 5, and Liquid Auduio 6?

3. Is it only possible to play lqt-files in winamp made from Liqufier Pro with lqm2lqt.exe, or is it also possible to play lqt-files made from Liquid Audio 5 ->(using liquidsplit1.06 I never got this working)

4. The aac-encoding in Liquid audio is FhG. Is this their best mpeg2-aac codec, or are they soon coming out with something even better?

5. The liqufier pro 24 program has also mp3 and ac3 encoding, and one can really experiment with the settings of the differnt formats. Example one can set up the prog to encode mp3 in 44,1kHz ms-stereo with full frequency band(22kHz) in only 64kbits/s, and same settings can be done for ac3. INSANE! But, fooling around with the bitrate control, it showed that MP3 heavily suffered from underwaterartifacts and ringing, while ac3 suffered more from pre-echo. Does this mean that to prevent pre-echo one gets other artifacts instead, like underwatereffect. So mp3 (lame & FhG), tries to prevent pre-echo by adding noise(undrewatereffects etc.) to the music, while ac3 isn't trying to prevent pre-echo in same degree, but at the positive side therefore has less noise and thus keeping the tonal-purity better? Well, I've read something like this in an pdf from http://www.adaptedwave.com/.

6. What sort of FhG-MP3 codec is implemented liquifier pro 24?

7. Would mp3s made with LP24 be better than mp3s made with other codecs in low bitrates? (128kbits and below)

8. Are AC3s made with liquid aidio better than those made with sound forge soft-enc 5.1? Or is it the same codec?

Thanks

about: AAC, Liquifier pro, mp3 etc.

Reply #1 –
Quote
Originally posted by Loke
4. The aac-encoding in Liquid audio is FhG. Is this their best mpeg2-aac codec, or are they soon coming out with something even better?


AAC encoding in liquifier is based on FhG AACdemo 3.0. It's their consumer/fast codec.

The Professional/Slow AAC encoder from FhG, AACdemo 2.2, produces best AAC quality so far. But it probably won't be included in Liquifier, now you will find in on the Net. Only few blessed people have it.

about: AAC, Liquifier pro, mp3 etc.

Reply #2 –
FhG's "slow" AAC encoder is not used in any consumer product. Who knows for what are they keeping it

Next version of LiquidAudio will use Dolby's Consumer AAC encoder. This encoder is very fast (working 13x faster than real-time on PIII 1.1 GHz), but it is worse than slow ("professional") AAC encoders.

-production switch will be obsolete in the next version of PsyTEL AACEnc.

Now, regarding quality (FhG vs. PsyTEL) - at 128 kbps it is now really close - I'm having a hard time finding samples that are obviously worse than FhG (some samples have some issues - but they are very close to FhG) and some other samples even sound better than LiquidAudio implementation of FhG AAC (testsignal2.wav for example) - at 96 Kb/s it is problematic, as FhG still sounds better for some critical items, but not much better anymore.

I think that VBR implementation in psytel encoder has greater efficiency than FhG's VBR implementation.

about: AAC, Liquifier pro, mp3 etc.

Reply #3 –
Quote
Originally posted by Ivan Dimkovic
FhG's "slow" AAC encoder is not used in any consumer product. Who knows for what are they keeping it


Isn't the Professional codec used in the Telos' hardware AAC encoder?
http://www.telos-systems.com/zephyr/default.htm

about: AAC, Liquifier pro, mp3 etc.

Reply #4 –
Well... I wouldn't call a device which costs $XXXX.xx "consumer"

Anyway, it uses DSP implementation of AAC, which is also worse than "simulation" software-only implementation (because of requirements for real-time execution, low voltage, etc..)

about: AAC, Liquifier pro, mp3 etc.

Reply #5 –
Quote
Originally posted by Ivan Dimkovic
Well... I wouldn't call a device which costs $XXXX.xx "consumer"


Woops... sorry, I didn't notice you were talking about consumer implementations only.

In this case, do you know about any "Profesional" ($$$$$)  software using FhG's AACdemo2.2 implementation?

about: AAC, Liquifier pro, mp3 etc.

Reply #6 –
No, sorry - I remember they mentioned that one company will "soon" implement AAC in their product, but so far I haven't heard for it yet.

Anyway, AAC 2.2 is not some kind of "magic wand" - it does sound better at 128 kbps than LiquidAudio AAC, but not much better - I am quite sure that most listeners won't be able to hear the difference. I can hear difference, but neither of these is 'transparent' at 128 kbps for worst-case items (castanets, velvet, ...)

about: AAC, Liquifier pro, mp3 etc.

Reply #7 –
I had Liquifier Pro 4.0 and 5.0 b24. Both were a pain in the ass, 5.0 even more than 4.0. The AAC quality was very good, but still, the proprietary format annoys me.

about: AAC, Liquifier pro, mp3 etc.

Reply #8 –
Interesting thing is that both Envivio AND Philips are using their own AAC implementations in their MPEG-4 products, instead of FhG/Dolby/AT&T AAC implemetnation. Who knows how much money they require for a "know-how" license

about: AAC, Liquifier pro, mp3 etc.

Reply #9 –
Have you already compared quality of Envivio's and Philips' AAC with Psytel?

about: AAC, Liquifier pro, mp3 etc.

Reply #10 –
Let's just say they are inferior ;-)

But I am in no position to tell anything more

about: AAC, Liquifier pro, mp3 etc.

Reply #11 –
Quote
Originally posted by Ivan Dimkovic

Now, regarding quality (FhG vs. PsyTEL) - at 128 kbps it is now really close - I'm having a hard time finding samples that are obviously worse than FhG (some samples have some issues - but they are very close to FhG) and some other samples even sound better than LiquidAudio implementation of FhG AAC (testsignal2.wav for example) - at 96 Kb/s it is problematic, as FhG still sounds better for some critical items, but not much better anymore.


sounds great! Keep up the good work!

And I have an other question for you, Ivan

Is it any truth in what I asked in nr.6, that methodes trying to prevent pre-echo, adds noise(other artifacts) to the sound, perhaps like underwatereffect and ringing etc, so the audioprogrammers have to make a compromise of which artifacts they want less of?
In an article from http://www.adaptedwave.com/ they say :(quote) Due to the large minimum window size of the MDCT, all MDCT-based codecs(MP3 AAC ..)are subject to pre-echo. All MDCT-based codecs must perform post-transformation processing, typically adding noise to the signal, to mask the pre-echo. This makes it impossible for MDCT-based codecs to provide trulytransparent audio quality.

As a aac-programmer you surely know, Is this true? As I understand it: To prevent pre-echo other artifacts are introduced.

about: AAC, Liquifier pro, mp3 etc.

Reply #12 –
No, not quite correct.

See, in transform based codecs you basically need to solve one trade-off:  frequency or time resolution?  Higher the frequency resolution, lower the time resolution and vice versa.

By switching to short blocks, you are reducing the frequency resolution of the encoder, for the sake of better time-resolution.

However, careful calculations show that combination used AAC window size (1024/128) is the best for music signals. Short blocks are relatively rare and AAC usually has very good frequency resolution. Additional tool for shaping the noise is also used, and it is called 'TNS'

By switching to 'short block' mode efficiency is reduced, but good implementation will allocate more bits than "average" and compensate all problems.

about: AAC, Liquifier pro, mp3 etc.

Reply #13 –
Hmm
I'm not sure if I understand it all.
What sort of audible artifact does "high frequency resolution on the cost of low time resolution" lead to, and what artifct are typical for "low frequency resolution".

And, BTW, isn't LAME only using short-blocks?

about: AAC, Liquifier pro, mp3 etc.

Reply #14 –
High-time resolution leads to weak frequency resolution ("chirps")
High-frequency resolution leads to weak time resolution ("pre-echoes")

Now, even short-blocks in AAC have "pre-echoes" but pre-echo in the short block is masked by the human "pre-masking" phenomenon, and it is not audible.

LAME is using short blocks only when necessary - same goes for PsyTEL AACEnc.

about: AAC, Liquifier pro, mp3 etc.

Reply #15 –
To continue

MP3 has short blocks, too - but the length of a short block is not enough to compensate pre-echo at 128 kbps.

AAC short block length is quite enough (2.5 ms) and the echo spread over the analysis window is masked by human perception (pre-masking goes up to 5 ms before sound event! and even 10 ms in some binaural configurations)

Some pictures:

ORIGINAL:



MP3 at 128:



AAC at 128:

about: AAC, Liquifier pro, mp3 etc.

Reply #16 –
Nice show  ...However, one other possible weakness of the switching scheme is the bad frequency response of the transition filter...although the system is still PR, quantization might introduce serious aliasing here...
Also, the switching is done rather ad hoc, in the sense that look-ahead is rather limited and based on energy criteria. A rate-distortion solution would probably be more optimal...

about: AAC, Liquifier pro, mp3 etc.

Reply #17 –
Switching criterion is not defined by the standard, so far I've seen several ways to do efficient block switching, and some of them are taking analysis-by-synthesis methods (like estimating pre-echo) into account. Some others are very "dumb" and work in time-domain based on energy difference.

Now, for switching there are special 'Start' and 'Stop' windows, designed especially for transition cases, to allow smooth continuous transition to 'short' mode, without quantization problems (if you know how to adapt psychoacoustics, of course - but that is what ISO docs won't tell you

Also, there are other methods employed in modern codecs as well - increasing of the bitrate for 'attack' frame as well as applying TNS filtering for long windows that contain localization of the noise not enough for the short block switching.

All in all, with good tuning - the system performs very well on wide range of signals - and with one big advantage over 'subband' coders - excellent frequency resolution and ability to encode with good quality at very low bitrates (16-24:1)

about: AAC, Liquifier pro, mp3 etc.

Reply #18 –
Quote
Originally posted by Ivan Dimkovic
Switching criterion is not defined by the standard, so far I've seen several ways to do efficient block switching, and some of them are taking analysis-by-synthesis methods (like estimating pre-echo) into account. Some others are very "dumb" and work in time-domain based on energy difference.]


Any further hints on which implementations use A-by-S?

Quote
Now, for switching there are special 'Start' and 'Stop' windows, designed especially for transition cases, to allow smooth continuous transition to 'short' mode, without quantization problems (if you know how to adapt psychoacoustics, of course - but that is what ISO docs won't tell you


Are these windows the ones obtained by combining the tails of the long/short windows?

Quote
All in all, with good tuning - the system performs very well on wide range of signals - and with one big advantage over 'subband' coders - excellent frequency resolution and ability to encode with good quality at very low bitrates (16-24:1)


True, but for off-line coding (assuming no memory/delay issues) a quantization scheme that can handle quantization in time (per channel, subband method) as well as in frequency (combined frequency lines, transform method) would give even better results...

about: AAC, Liquifier pro, mp3 etc.

Reply #19 –
Quote
Originally posted by petracci
Any further hints on which implementations use A-by-S?


I've seen some papers, sorry but I can't remember exactly what methods were used, but I suppose you could estimate amount of "pre-echo" by the amount of allowed noise and impulse localization (you have analysis window properties)

Quote
Are these windows the ones obtained by combining the tails of the long/short windows?


Yes

Quote
True, but for off-line coding (assuming no memory/delay issues) a quantization scheme that can handle quantization in time (per channel, subband method) as well as in frequency (combined frequency lines, transform method) would give even better results...


Right, TNS in AAC is one approach that tries to join that "two worlds" (time and frequency quantization) - wavelets might be another interesting issue here, but so far there are no remarkable results with them..

about: AAC, Liquifier pro, mp3 etc.

Reply #20 –
Quote
Originally posted by Ivan Dimkovic

Right, TNS in AAC is one approach that tries to join that "two worlds" (time and frequency quantization) - wavelets might be another interesting issue here, but so far there are no remarkable results with them..


This adaptedwave-compagny seems to have implemented a nice wavelet packet scheme, though.....and they have Coifman on the board (he practically invented WPs  ), so who knows....Did you hear of them before?

about: AAC, Liquifier pro, mp3 etc.

Reply #21 –
No, but I will check it out - the biggest problem with wavelet coders is design of a good wavelet and psychoacoustic model working in wavelet domain - this is of course a topic for further research.