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: QAAC: discussion, questions, feature requests, etc. (Read 687102 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

QAAC: discussion, questions, feature requests, etc.

Reply #475 –
@ nu774

Regarding the new DRC switch in qaac 2.26, do you have plans to add any presets that might mimic the effects of the "light", "normal", and "heavy" DRC options present in Dolby Digital? I expect the layman won't know how to use the five parameters effectively, so having a few demonstration modes might be beneficial. Thanks for continuing to work on the frontend!

QAAC: discussion, questions, feature requests, etc.

Reply #476 –
Quote from: Aleron Ives on
Regarding the new DRC switch in qaac 2.26, do you have plans to add any presets that might mimic the effects of the "light", "normal", and "heavy" DRC options present in Dolby Digital? I expect the layman won't know how to use the five parameters effectively, so having a few demonstration modes might be beneficial.

While your request is reasonable, I don't think it's possible to mimic Dolby ATSC DRC profiles.
As far as I know Dolby has 5 thresholds and does both upward/downward compression, while qaac only provides very simple one threshold + downward compression.
Chaining multiple qaac instances with different --drc, --gain options might make it possible to achieve somewhat similar effects, but I'm not sure.

To tell the truth, I'm not confident of usefulness of this new option. If somebody have any thought on this, I'd like to hear feedback.

QAAC: discussion, questions, feature requests, etc.

Reply #477 –
I was actually looking through qaac's documentation a few weeks ago to see if it had such functionality, so it is interesting that you decided to add the feature now.

Does the -N switch use the ReplayGain algorithm, or does it use peak normalisation? My guess is that it uses the latter, since the file I tried normalising ended up clipping. You might be able to implement both normalisation and DRC using a methodology similar to MP3Gain/AACGain, i.e. rather than scaling the audio prior to encoding, you could adjust the global gain values of each frame. Not only would this allow you to implement lossless gain adjustment (since MP3Gain writes APEv2 tags to provide the information necessary to undo the volume adjustment), but it would also potentially allow qaac to normalise or apply DRC to existing AAC files without transcoding them. The 1.5 dB steps might not allow for the same level of precise volume adjustment as Dolby's DRC implementation, but I suspect it would be more than capable of achieving the desired effect.

QAAC: discussion, questions, feature requests, etc.

Reply #478 –
Quote from: Aleron Ives on
Does the -N switch use the ReplayGain algorithm, or does it use peak normalisation? My guess is that it uses the latter

Correct.

Quote from: Aleron Ives on
You might be able to implement both normalisation and DRC using a methodology similar to MP3Gain/AACGain, i.e. rather than scaling the audio prior to encoding, you could adjust the global gain values of each frame.

Your idea is reasonable, and actually I've heard similar request for "replaygain in qaac" several times.
HOWEVER, like you say what it does is not encoding, but modifying the already encoded AAC bitstream, and can very well implemented as an independent tool.
Actually, it shares almost zero functionality with encoder. To implement it, qaac actually has to start from decoding the AAC bitstream that has just been encoded. No better than other tools like aacgain. So, I'd rather want to see it implemented in different tool. Not in qaac.
I WON'T implement MP4 tag editor in qaac for the very same reason.

And don't forget qaac not only is an AAC LC encoder but also supports SBR, ALAC, PCM output.

QAAC: discussion, questions, feature requests, etc.

Reply #479 –
As for dynamic range compression, At least 3 choices come to mind.
1. Directly compress PCM signals before encoding (what qaac --drc does)
2. Modify global gain value (aacgain way, works for LC only)
3. Set DRC metadata (present in AAC spec)

Third option is similar to what is used by AC3 or something, and looks best IF it is supported by wide range of decoders... but as far as I know it seems not.
Since 2 and 3 work on per frame basis, it's impossible for them to achieve as fine grained control as 1, and probably they are not suitable for subtle compression what is done on mastering or something. However, since we are not mastering but just encoding here, it shouldn't be a big problem.

QAAC: discussion, questions, feature requests, etc.

Reply #480 –
Quote from: nu774 on
I'd rather want to see it implemented in different tool.

My current solution is to run files through WaveGain prior to encoding if I need RG adjustment, which works well enough.

Quote from: nu774 on
Since 2 and 3 work on per frame basis, it's impossible for them to achieve as fine grained control as 1, and probably they are not suitable for subtle compression what is done on mastering or something. However, since we are not mastering but just encoding here, it shouldn't be a big problem.

I would tend to agree. If users desired a mastering-calibre compression algorithm, they probably wouldn't be targetting a lossy format.

QAAC: discussion, questions, feature requests, etc.

Reply #481 –
[qaac] release 2.27 (refalac 1.27)
posted 48 minutes ago by nu 774
Now you can set --drc option twice or more, with different parameters. This can be used to obtain more complex effect.

For example, you can use --drc for normal compression, then as a limiter (--drc with high thresh + high ratio + zero attack/release will work something like a limiter, that effectively kills remaining peaks).

https://sites.google.com/site/qaacpage/cabinet

QAAC: discussion, questions, feature requests, etc.

Reply #482 –
Those it have the feature that i know many would like.

A Transparent option.

Or more like, you sert to a quality where the encoder will try to achieve transparency.

Cause currently, let´s say a certain music file can be transparent easily at 164kbps.

But if you set, "Variable at 320kbps", it will probably become 300-340kbps, even though that is unnecessary.

Though of course, transparency it not something that´s achieved at a precise point, but i think there has been discussion about it.
I know people asked for it in OPUS, me included.

QAAC: discussion, questions, feature requests, etc.

Reply #483 –
I don't think it is possible. How will the encoder know if it is reaching transparency for your ears?

QAAC: discussion, questions, feature requests, etc.

Reply #484 –
Quote from: LithosZA on
I don't think it is possible. How will the encoder know if it is reaching transparency for your ears?



Yeah as you say, that is the fundamental problem.
But i think some sort of "sensor" to try to achieve allow only a certain magnitude of distortion.

A clever search implementation, something that knows "If it is this much distorted, than it will surely be noticeable".

If you think about Lossless vs Lossy a bit.

For example, let´s say FLAC can make a file 200kbps.

But if you encode that with anything, like QAAC, and set, Variable at 320kbps, it will surely use more than 200kbps.

It doesn´t know that it can be Lossless at 200kbps, which means that it should be able to achieve total transparency at 200kbps or less.

But i know you also can´t compare them, as Lossy completely obliterate Lossless, so it can´t achieve it no matter what, as Jpeg vs Png.
I just wanted to point out that "problem", but i also think it´s easier said than done.

QAAC: discussion, questions, feature requests, etc.

Reply #485 –
If you don't want Constrained VBR, use the True VBR mode.

QAAC: discussion, questions, feature requests, etc.

Reply #486 –
Quote from: AndersHu on
If you don't want Constrained VBR, use the True VBR mode.


That works similar to CRF in x264 if i am not to far off?

Haven´t really tried it, but it goes to 127 in quality i think.
And i don´t quite get it. 127, is that suppose to mean, Guaranteed top quality possible with that encoder, or something like that?
For x264 that would possible be, CRF 1, as 0 means lossless.

x264 = h264 encoder, anything with h264 is the same though, but usually write "x" as i am used to it.

QAAC: discussion, questions, feature requests, etc.

Reply #487 –
Quote from: zerowalker on
And i don´t quite get it. 127, is that suppose to mean, Guaranteed top quality possible with that encoder, or something like that?

Q0 - Q4 (0) = ~40 kbps
Q5 - Q13 (9) = ~45 kbps
Q14 - Q22 (18) = ~75 kbps
Q23 - Q31 (27) = ~80 kbps
Q32 - Q40 (36) = ~95 kbps
Q41 - Q49 (45) = ~105 kbps
Q50 - Q58 (54) = ~115 kbps
Q59 - Q68 (63) = ~135 kbps
Q69 - Q77 (73) = ~150 kbps
Q78 - Q86 (82) = ~165 kbps
Q87 - Q95 (91) = ~195 kbps
Q96 - Q104 (100) = ~225 kbps
Q105 - Q113 (109) = ~255 kbps
Q114 - Q122 (118) = ~285 kbps
Q123 - Q127 (127) = ~320 kbps

QAAC: discussion, questions, feature requests, etc.

Reply #488 –
So in other words, it´s Constrained Variable Bitrate, but with another Currency or what to call it?

QAAC: discussion, questions, feature requests, etc.

Reply #489 –
No, those are merely general bitrate ranges that the encoder often produces on the tracks that people have tested. Other tracks can go above or below those averages, and the bitrate fluctuates during the tracks as necessary to achieve the desired quality.

You are correct that the VBR scale in Apple's encoder is similar to the CRF scale in x264. What you seem to be missing is that both the VBR scale and the ratefactor scale are in arbitrary units that have no numerical quality equivalent. That is to say the 8-bit CRF scale of 0 - 51 is arbitrary, as is the VBR scale of 0 - 127. The way you use both scales is the same: you start at a "bad" quality that you can easily ABX and start increasing the quality setting until you can't ABX the results anymore. Once you reach transparency, you know that you should use that setting for most, if not all, of your encodes. The only difference between testing x264 CRF values and AAC VBR values is that it's harder to perform ABX tests on video than it is on audio, as I am not aware of any video ABX comparators.

The fact that all listeners must perform these tests to determine their individual transparency thresholds is the reason why qaac does not have a "transparency" VBR setting: transparency is achieved at different bitrates for different people, and thus it cannot be standardised into a qaac preset.

QAAC: discussion, questions, feature requests, etc.

Reply #490 –
@zerowalker
If you think VBR is not as variable in bitrate as you think, try some extra ordinary case like the following:
Code: [Select]
sox -n -t wav - synth 5 sin 1000 | qaac -V127 - -o foo.m4a

This pipeline encodes a simple sine wave, and results in 18kbps or so in true VBR quality 127. On CVBR it goes a bit higher, but you might notice that it is not as constrained as you think.

And if you think VBR is not as constant quality as you think (yeah, some difficult samples can be easier to ABX than other), just accept it. Although VBR encoder tries it's best to achieve constant quality, world is no that ideal.

And at last, do you know qaac is merely a frontend to Apple's encoder?
qaac cannot do anything better than just setting parameters for quality control already provided as command line options.

QAAC: discussion, questions, feature requests, etc.

Reply #491 –
Regarding CVBR and TVBR, has there been any wide-range comparison between the two methods? I've always used TVBR @ q82 for my movie audio track re-encodes.

QAAC: discussion, questions, feature requests, etc.

Reply #492 –
Ah, well then i understand them quite correctly.
And as you say Video is on a different level.

The different in content changes alot, while Audio content doesn´t really matter that much when you set a quality level.

Learned something about doing the tests to know your "transparent setting", even though i am crappy at noticing distortions as long as it´s above 128kbps or something.
So i often just take the highest possible settings to know that it will be transparent, if not for some extremely rare cases of course.

QAAC: discussion, questions, feature requests, etc.

Reply #493 –
Quote from: Boulder on
Regarding CVBR and TVBR, has there been any wide-range comparison between the two methods? I've always used TVBR @ q82 for my movie audio track re-encodes.

The overall quality difference of CVBR and TVBR is very small.
http://listening-tests.hydrogenaudio.org/i...-96-a/index.htm
http://www.hydrogenaudio.org/forums/index....showtopic=97913

QAAC: discussion, questions, feature requests, etc.

Reply #494 –
What is it with AAC and my ears, I wonder.
Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.2.9
2013/12/08 17:40:37

File A: R:\03 蒼空にくちづけたら_-v256.m4a
File B: R:\03. ゆうまお - 蒼空にくちづけたら.flac

17:40:37 : Test started.
17:42:03 : 01/01  50.0%
17:42:49 : 02/02  25.0%
17:43:29 : 02/03  50.0%
17:43:55 : 03/04  31.3%
17:44:17 : 04/05  18.8%
17:44:58 : 05/06  10.9%
17:45:34 : 05/07  22.7%
17:45:57 : 06/08  14.5%
17:46:18 : 07/09  9.0%
17:47:04 : 08/10  5.5%
17:47:07 : Test finished.

 ---------- 
Total: 8/10 (5.5%)

If I had to describe it, aac sounds kind of "electronic" or "metallic" to my ears. I struggle ABXing mp3 at this bitrate, but AAC is so obvious. Though I'd say nero's aac encoder did an even poorer job. Or maybe this song is just a problem sample.

QAAC: discussion, questions, feature requests, etc.

Reply #495 –
Quote from: ChronoSphere on
If I had to describe it, aac sounds kind of "electronic" or "metallic" to my ears. I struggle ABXing mp3 at this bitrate, but AAC is so obvious. Though I'd say nero's aac encoder did an even poorer job. Or maybe this song is just a problem sample.

It's a very interesting sample, as Apple AAC is the mighty encoder, and the likelihood of defects are very small. Could you upload the problematic section of the song in FLAC, so that we can reproduce the result?

QAAC: discussion, questions, feature requests, etc.

Reply #496 –
uploaded the sample here. First time doing this, is this how I was supposed to do it?

QAAC: discussion, questions, feature requests, etc.

Reply #497 –
ChronoSphere my compliments, I can't even ABX @~96kbps with Vorbis, AAC and Opus. I guess it also depends how hard you try. I realized long time ago if I have to try for more than 10 mins it means the codec is good enough.

QAAC: discussion, questions, feature requests, etc.

Reply #498 –
Quote from: ChronoSphere on
uploaded the sample here. First time doing this, is this how I was supposed to do it?
Exactly. And I reproduced the result, although at cvbr 192kbps. This is a good critical sample, because of the sharp transient attack, crystal vocal, and background silence.
Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.2.9
2013/12/09 02:52:06

File A: 蒼空にくちづけたら.wav
File B: 蒼空にくちづけたら.mp4

02:52:06 : Test started.
02:52:47 : 01/01  50.0%
02:53:52 : 02/02  25.0%
02:54:10 : 03/03  12.5%
02:54:40 : 03/04  31.3%
02:54:59 : 04/05  18.8%
02:55:23 : 05/06  10.9%
02:55:56 : 06/07  6.3%
02:56:24 : 06/08  14.5%
02:56:51 : 07/09  9.0%
02:57:21 : 08/10  5.5%
02:57:24 : Test finished.

 ---------- 
Total: 8/10 (5.5%)

QAAC: discussion, questions, feature requests, etc.

Reply #499 –
Quote from: eahm on
ChronoSphere my compliments, I can't even ABX @~96kbps with Vorbis, AAC and Opus. I guess it also depends how hard you try. I realized long time ago if I have to try for more than 10 mins it means the codec is good enough.
Thank you, though I didn't think my hearing to be that good. Incidentally, I tested opus and vorbis for this track, too in the past, and I stopped trying at 192kbps average for both of them. 160kbps was already near my limit, actually, as you can see below. Which is why I'm so surprised about AAC behaving so badly in comparison. Each test takes me about 3-4 minutes I guess.

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.2.9
2013/12/08 17:54:25

File A: R:\03. ???? - ?????????.flac
File B: R:\03 ?????????_160.opus

17:54:25 : Test started.
17:55:27 : 01/01  50.0%
17:55:54 : 01/02  75.0%
17:56:20 : 01/03  87.5%
17:56:47 : 02/04  68.8%
17:57:04 : 03/05  50.0%
17:57:52 : 04/06  34.4%
17:58:40 : 04/07  50.0%
17:59:08 : 05/08  36.3%
17:59:25 : 06/09  25.4%
17:59:40 : 07/10  17.2%
18:00:24 : Test finished.

 ---------- 
Total: 7/10 (17.2%)