IPB

Welcome Guest ( Log In | Register )

25 Pages V  « < 18 19 20 21 22 > »   
Reply to this topicStart new topic
QAAC: discussion, questions, feature requests, etc., [originally a thread for a feature request]
Aleron Ives
post Nov 10 2013, 08:08
Post #476





Group: Members
Posts: 167
Joined: 22-March 10
From: California
Member No.: 79208



@ 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!
Go to the top of the page
+Quote Post
nu774
post Nov 10 2013, 10:17
Post #477





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (Aleron Ives @ Nov 10 2013, 16:08) *
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.

This post has been edited by nu774: Nov 10 2013, 10:18
Go to the top of the page
+Quote Post
Aleron Ives
post Nov 12 2013, 02:16
Post #478





Group: Members
Posts: 167
Joined: 22-March 10
From: California
Member No.: 79208



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.
Go to the top of the page
+Quote Post
nu774
post Nov 12 2013, 03:36
Post #479





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (Aleron Ives @ Nov 12 2013, 10:16) *
Does the -N switch use the ReplayGain algorithm, or does it use peak normalisation? My guess is that it uses the latter

Correct.

QUOTE (Aleron Ives @ Nov 12 2013, 10:16) *
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.

This post has been edited by nu774: Nov 12 2013, 03:37
Go to the top of the page
+Quote Post
nu774
post Nov 12 2013, 04:08
Post #480





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



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.

This post has been edited by nu774: Nov 12 2013, 04:08
Go to the top of the page
+Quote Post
Aleron Ives
post Nov 12 2013, 08:12
Post #481





Group: Members
Posts: 167
Joined: 22-March 10
From: California
Member No.: 79208



QUOTE (nu774 @ Nov 11 2013, 18:36) *
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 (nu774 @ Nov 11 2013, 19:08) *
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.
Go to the top of the page
+Quote Post
sluggy
post Nov 12 2013, 15:38
Post #482





Group: Members
Posts: 54
Joined: 22-June 12
Member No.: 100900



[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
Go to the top of the page
+Quote Post
zerowalker
post Nov 15 2013, 13:01
Post #483





Group: Members
Posts: 239
Joined: 6-August 11
Member No.: 92828



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.
Go to the top of the page
+Quote Post
LithosZA
post Nov 15 2013, 15:13
Post #484





Group: Members
Posts: 182
Joined: 26-February 11
Member No.: 88525



I don't think it is possible. How will the encoder know if it is reaching transparency for your ears?
Go to the top of the page
+Quote Post
zerowalker
post Nov 15 2013, 15:21
Post #485





Group: Members
Posts: 239
Joined: 6-August 11
Member No.: 92828



QUOTE (LithosZA @ Nov 15 2013, 16:13) *
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.
Go to the top of the page
+Quote Post
AndersHu
post Nov 15 2013, 17:20
Post #486





Group: Members
Posts: 29
Joined: 2-April 06
Member No.: 29111



If you don't want Constrained VBR, use the True VBR mode.
Go to the top of the page
+Quote Post
zerowalker
post Nov 15 2013, 18:26
Post #487





Group: Members
Posts: 239
Joined: 6-August 11
Member No.: 92828



QUOTE (AndersHu @ Nov 15 2013, 18:20) *
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.
Go to the top of the page
+Quote Post
eahm
post Nov 15 2013, 18:38
Post #488





Group: Members
Posts: 889
Joined: 11-February 12
Member No.: 97076



QUOTE (zerowalker @ Nov 15 2013, 10:26) *
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

This post has been edited by eahm: Nov 15 2013, 18:38
Go to the top of the page
+Quote Post
zerowalker
post Nov 15 2013, 19:16
Post #489





Group: Members
Posts: 239
Joined: 6-August 11
Member No.: 92828



So in other words, itīs Constrained Variable Bitrate, but with another Currency or what to call it?
Go to the top of the page
+Quote Post
Aleron Ives
post Nov 15 2013, 23:22
Post #490





Group: Members
Posts: 167
Joined: 22-March 10
From: California
Member No.: 79208



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.
Go to the top of the page
+Quote Post
nu774
post Nov 16 2013, 02:12
Post #491





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



@zerowalker
If you think VBR is not as variable in bitrate as you think, try some extra ordinary case like the following:
CODE
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.
Go to the top of the page
+Quote Post
Boulder
post Nov 16 2013, 11:09
Post #492





Group: Members
Posts: 34
Joined: 12-February 06
Member No.: 27717



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.
Go to the top of the page
+Quote Post
zerowalker
post Nov 16 2013, 14:08
Post #493





Group: Members
Posts: 239
Joined: 6-August 11
Member No.: 92828



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.
Go to the top of the page
+Quote Post
Kamedo2
post Nov 16 2013, 14:29
Post #494





Group: Members
Posts: 168
Joined: 16-November 12
From: Kyoto, Japan
Member No.: 104567



QUOTE (Boulder @ Nov 16 2013, 19:09) *
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
Go to the top of the page
+Quote Post
ChronoSphere
post Dec 8 2013, 17:51
Post #495





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



What is it with AAC and my ears, I wonder.
CODE
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.

This post has been edited by ChronoSphere: Dec 8 2013, 17:51
Go to the top of the page
+Quote Post
Kamedo2
post Dec 8 2013, 17:58
Post #496





Group: Members
Posts: 168
Joined: 16-November 12
From: Kyoto, Japan
Member No.: 104567



QUOTE (ChronoSphere @ Dec 9 2013, 01:51) *
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?
Go to the top of the page
+Quote Post
ChronoSphere
post Dec 8 2013, 18:44
Post #497





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



uploaded the sample here. First time doing this, is this how I was supposed to do it?
Go to the top of the page
+Quote Post
eahm
post Dec 8 2013, 18:58
Post #498





Group: Members
Posts: 889
Joined: 11-February 12
Member No.: 97076



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.

This post has been edited by eahm: Dec 8 2013, 19:02
Go to the top of the page
+Quote Post
Kamedo2
post Dec 8 2013, 19:02
Post #499





Group: Members
Posts: 168
Joined: 16-November 12
From: Kyoto, Japan
Member No.: 104567



QUOTE (ChronoSphere @ Dec 9 2013, 02:44) *
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
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%)
Go to the top of the page
+Quote Post
ChronoSphere
post Dec 8 2013, 19:56
Post #500





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



QUOTE (eahm @ Dec 8 2013, 18:58) *
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
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%)
Go to the top of the page
+Quote Post

25 Pages V  « < 18 19 20 21 22 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th April 2014 - 04:57