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 689754 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

QAAC: discussion, questions, feature requests, etc.

Reply #625 –
The C in CVBR is a little confusing, compared to the C in Constant Bitrate.

Comparing constant and variable bitrate modes, your result will have either a rather constant bitrate or a rather constant quality. The former is only interesting for narrow bandwidth transmissions or where an obsolete container format requires it. Well, it would possibly not even support AAC at all. So whereever possible, one should prefer variable bitrate, and if it doesn't need to be Constrained, go for True Variable Bitrate.

QAAC: discussion, questions, feature requests, etc.

Reply #626 –
Quote from: o-l-a-v on
I'd go tvbr -127. AFAIK cvbr is made if you want to achieve a given bitrate = quality is not 1st priority. TVBR on the other hand has quality as its' primary goal.


Quote from: LigH on
Comparing constant and variable bitrate modes, your result will have either a rather constant bitrate or a rather constant quality. The former is only interesting for narrow bandwidth transmissions or where an obsolete container format requires it. Well, it would possibly not even support AAC at all. So whereever possible, one should prefer variable bitrate, and if it doesn't need to be Constrained, go for True Variable Bitrate.


But from my experiments so far, CVBR produces the largest files of all modes at 320 kbps, and overall bitrate of CVBR-encoded files is routinely above 320 (and never below 320), on some tracks I've encoded so far it goes up to 380 kbps. So shouldn't that mean best quality? Isn't True VBR all about having the best efficiency? From what I've read so far, Constrained VBR actually sets a minimum bitrate, and is allowed to go up if necessary, whereas True VBR has no minimum bitrate, isn't that correct?

QAAC: discussion, questions, feature requests, etc.

Reply #627 –
"The highest average bitrate" does not certainly mean "the highest possible quality", but possibly rather "the same quality may have been achieved with less waste". This explanation regarding a minimum bitrate may be true; there is a chance that it is achieved by stuffing the file with useless junk.

QAAC: discussion, questions, feature requests, etc.

Reply #628 –
Quote from: tahaa7 on
From what I've read so far, Constrained VBR actually sets a minimum bitrate, and is allowed to go up if necessary, whereas True VBR has no minimum bitrate, isn't that correct?

Not exactly. For example, try encoding sine wave with CVBR 320kbps. If it doesn't really need bits like in this case, bitrate will go much lower.
However, also try encoding with --gain -50 or something like that (this makes input _VERY_ quiet). TVBR will aggressively cut bitrate for this ("Hey, this is too quiet and barely audible. Let's give bits for other parts!"), but CVBR does not so much.

QAAC: discussion, questions, feature requests, etc.

Reply #629 –
[qaac] release 2.38 (refalac 1.38)
posted an hour ago by nu 774

Allow nesting of ${} in --fname-format.
Now you can write something like ${albumartist|${artist}} for example, which means:

When album artist tag is present and non-empty, it evaluates to album artist tag's value.
Otherwise, it evaluates to artist tag's value.

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

QAAC: discussion, questions, feature requests, etc.

Reply #630 –
[qaac] release 2.39 (refalac 1.39)
posted 26 minutes ago by nu 774

Added dedicated MP4 reader, which supports:

Deconding AAC-LC, MP1/2/3, ALAC (qaac), ALAC (refalac).
Perfectly support files with iTunSMPB and multiple edits. In files with multiple edits, there exist multiple valid spans to be played back. In other words, there are multiple gaps to be skipped. As far as I know, there is NO such software that supports it properly. If you are interested, try https://sites.google.com/site/qaacpage/cabi...tiple-edits.zip.

This file contains 3 edits in it. When properly decoded/played, it contains exactly 30 seconds music. However, in this file there are very short 2 gaps to be skipped in the middle as well as first delay and end padding. Therefore, no software other than qaac should play it correctly without pops/clicks exactly in 30 seconds.

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

QAAC: discussion, questions, feature requests, etc.

Reply #631 –
[qaac] release 2.40 (refalac 1.40)
posted an hour ago by nu 774

Fixed new MP4 decoder introduced at 2.39 (found seek related bug, and ALAC has been trimmed too much).

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

QAAC: discussion, questions, feature requests, etc.

Reply #632 –
I don't know if I can ask a question, here. The QAAC site sends me to this post, and I don't want to start a new topic for this question. I'm new in the digital audio world, so don't kill me. Also English is not my native language so excuse me for my grammarians errors.

Well I start, I'm tired of ripping my CDs everytime I decide to change from format or codec. I've been using QAAC for a year. When the source is Lossless I use TVBR 109 for Audio-CD (44,1 KHz) and TVBR 127 for DVD-Video with LPCM tracks (48 KHz). And when the source is Lossy I try differents TVBR qualities comparing with Spek from the original to the new one.

Now I want to keep in a Lossless format my CDs. So I don't have to keep ripping everytime I change my mind. I choose ALAC. I know that FLAC have a better compression ratio but I'm used to the iTunes world. Since my first iPod in 2007, iTunes became my favorite music player. So ALAC is the smartest desicion.

This is the situation. I usually use normalize in QAAC to keep the max volume per track of the same album. To do this with ALAC I put the WAVs of the uncompressed audio from the Audio-CD, in the same folder that QAAC. I run something like this:

qaac.exe --alac --concat --normalize -b 16 --verbose -o "1.m4a" *.wav

I delete the WAVs. I open 1.m4a with Foobar2000, it detects the tracks as chapters. I convert to WAV 16 bits with no dither to the same folder, one file per track. And I run:

qaac.exe --alac --verbose *.wav

I delete 1.m4a and I move the m4a files to my iTunes folder and start to fill with tags and that stuffs.

Now my question is this. Normalize convert the audio to float 32 bits. That's why i put -b 16. But I don't really know what this means. If:

a) The normalize filter is applied with an input of int 16 bit and the output is also int 16 bits
b) int 16 bits transform to float 32, the filter is applied, and then the bit depth is reduced to 16 bits using dither TPDF.

If the answer is a, it's perfect. But if it's b, I think I shouldn't use normalize since it applies dither and cause noise.

What do you think? Thank you.
 

QAAC: discussion, questions, feature requests, etc.

Reply #633 –
--normalize will multiply each sample by some floating point number. For example, when the original peak was -3dBFS and you want to make the new peak to be at around 0dBFS, you have to multiply each sample by 1.4 or something. Multiplying by 1.4 yields also float.. not integer.
-b16 will apply TPDF dither when it scales down bit depth. If you don't want that behavior, use --no-dither.

Having said that, I don't recommend --normalize for lossless archiving unless you have a special reason to do so. Once you have normalized, it means the result is NOT lossless (=identical) copy of the original CD even if you are using lossless codec, which means that you cannot check validity of the results using AccurateRip DB or something.

QAAC: discussion, questions, feature requests, etc.

Reply #634 –
If you want to play different songs with similar "loudness", but keep a lossless archive, I believe that techniques like ReplayGain may be more suitable. But they possibly can't help to equalize rather linear (e.g. classic) with dynamic-compressed (usually pop) sources either.

QAAC: discussion, questions, feature requests, etc.

Reply #635 –
Quote from: nu774 on
--normalize will multiply each sample by some floating point number. For example, when the original peak was -3dBFS and you want to make the new peak to be at around 0dBFS, you have to multiply each sample by 1.4 or something. Multiplying by 1.4 yields also float.. not integer.
-b16 will apply TPDF dither when it scales down bit depth. If you don't want that behavior, use --no-dither.

Having said that, I don't recommend --normalize for lossless archiving unless you have a special reason to do so. Once you have normalized, it means the result is NOT lossless (=identical) copy of the original CD even if you are using lossless codec, which means that you cannot check validity of the results using AccurateRip DB or something.


Thank you. I didn't understand why "--normalize" have to transform the bith depth to float. I won't be using that filter again since it applies dither and I don't want that. Except in special cases. For example I have a DVD of Madonna's concert S&S Tour released around 2010. I demuxed the PCM track, encoded to ALAC with QAAC with the "--raw" options and applied "--normalize" and in the analysis shows a peak around 0.4. In that case I think is useful to use --normalize. Not? If the answer is yes, should I let the dithering happens or should I use --no-dither.

Thank you

QAAC: discussion, questions, feature requests, etc.

Reply #636 –
Quote from: LigH on
If you want to play different songs with similar "loudness", but keep a lossless archive, I believe that techniques like ReplayGain may be more suitable. But they possibly can't help to equalize rather linear (e.g. classic) with dynamic-compressed (usually pop) sources either.


Thank you. I use ReplayGain. iTunes have it's own way, instead of writing the appropiate ReplayGain tag it writes iTunNORM tag. But I use beaTunes who writes both tags. Other players like Foobar2000 use the ReplayGain tag. ReplayGain make every song sound at the same volume. It's useful to a party, reunion o whatever when you play a list of songs and don't want to keep rising or decreasing the volume. But what it makes it's to decrease volume in almost all songs, except when the song is not very loud.

The reason why I used --normalize it's not for listening in my computer but in my iPod and my cellphone when the volume insufficient.

I think I won't be using --normalize for ALAC. When I want to transfer this song to iPod or cellphone I will encode to AAC with the normalize filter. I believe in lossy formats the bit depth it's not important.

QAAC: discussion, questions, feature requests, etc.

Reply #637 –
I'm trying to configure HE-AAC transcoding via QAAC for Subsonic, but I can't seem to figure out the HE-AAC.

I've got LC working via:

Step 1 - ffmpeg -i %s -f wav -
Step 2 - qaac -a %bk --adts - -o -

Can someone help on how to configure for HE-AAC?

QAAC: discussion, questions, feature requests, etc.

Reply #638 –
Sixth Street, is something like "qaac -v128 --he %bk --adts - -o -" working?

Please change after "--he" as you like, I don't even know if you can do --adts with --he. Also, as quoted from the CLI "HE AAC mode (TVBR is not available)" so, no -V, only -v, -c and -a.

QAAC: discussion, questions, feature requests, etc.

Reply #639 –
Checking a 5.1 M4A file created by QAAC using MediaInfo, you may notice a certain difference between two distinct values related to the "channel count". I would assume that MediaInfo just reports header values as they are found (is there another AAC / M4A analysis tool to compare?).

Is this a "bug" of QAAC (putting a wrong value in a header field), or based on a peculiarity of the AAC format (e.g. multichannel encoding being an extension to stereo since MPEG-2 BC audio)? ... Well, I may be wrong here, AAC is also known as MPEG-2 NBC (non backward compatible), so I hope there was no similar mistake.

Code: [Select]
General
Complete name                            : ToS_QAAC.m4a
Format                                   : MPEG-4
Format profile                           : Apple audio with iTunes info
Codec ID                                 : M4A 
File size                                : 37.4 MiB
Duration                                 : 12mn 14s
Overall bit rate mode                    : Variable
Overall bit rate                         : 427 Kbps
Encoded date                             : UTC 2014-06-04 06:30:09
Tagged date                              : UTC 2014-06-04 06:31:16
Writing application                      : qaac 2.38, CoreAudioToolbox 7.9.8.3, AAC-LC Encoder, TVBR q91, Quality 96

Audio
ID                                       : 1
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : 40
Duration                                 : 12mn 14s
Bit rate mode                            : Variable
Bit rate                                 : 426 Kbps
Maximum bit rate                         : 578 Kbps
Channel count                            : 2 channels
Original Channel count                   : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 48.0 KHz
Compression mode                         : Lossy
Stream size                              : 37.3 MiB (100%)
Encoded date                             : UTC 2014-06-04 06:30:09
Tagged date                              : UTC 2014-06-04 06:31:16

QAAC: discussion, questions, feature requests, etc.

Reply #640 –
mp4a.channelcount is intentionally set to either 1 or 2, since in the former spec (ISO 14496-12) only 1 or 2 was allowed. However, it seems that no such restriction present in the new spec (4th ed @2012-7-15). Therefore, maybe I should fix qaac to write actual number of channels.

On the other hand, I can say for sure that nothing in AudioSampleEntry (mp4a) matters and cannot be taken seriously.
For example, samplesize field (typically it is 16) is non-sense for AAC.
samplerate field is 16.16 fixed-point, so not enough to represent high samplerate such as 96kHz.
I don't understand why MediaInfo looks at it at all.

QAAC: discussion, questions, feature requests, etc.

Reply #641 –
[qaac] release 2.41 (refalac 1.41)
posted 6 hours ago by nu 774

Add --limiter. --limiter applies smart limiter that softly clips portions where peak exceeds (near) 0dBFS. Softly means that it applies non-linear filter to surrounding half cycles (nearest zero crossing point to zero crossing point) so that the result fits in under 0dBFS but still is smoothly connected to other parts, resulting in much smaller audible distortion than dumb hard clips.
For CVBR/ABR/CBR mode, bitrate value less than 8 is now treated as "bits per sample". Bitrate is computed as the following:
  Bitrate = bits_per_sample * number_of_channels * sample_rate
For example, --cvbr 2 is now equivalent for --cvbr 192 (=2*2*48000) for 2ch, 48kHz case. This can be useful when you want to use CVBR/ABR/CBR and want constant quality setting for varying number of channels or sample rate.
Other minor changes.

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

QAAC: discussion, questions, feature requests, etc.

Reply #642 –
nu774, why was foo_input_caf moved to "Old"?

QAAC: discussion, questions, feature requests, etc.

Reply #644 –
Anyone tried the new limiter option? Am I correct in thinking that it act's like a declip feature....kind of?

QAAC: discussion, questions, feature requests, etc.

Reply #645 –
Quote from: Carsi on
Anyone tried the new limiter option? Am I correct in thinking that it act's like a declip feature....kind of?

No. --limiter doesn't magically repair already hard clipped input (that is, peaks beyond 0dBFS are already cut off / thrown away).
Instead, --limiter works on floating point input that can hold peaks beyond 0dBFS and softly controls the amplitude so that output amplitude doesn't exceed the threshold.
Compare the following:
Code: [Select]
qaac --play --gain=6 -b16 foo.wav           # hard clip
qaac --play --gain=6 -b16 --limiter foo.wav  # soft clip

In this example, input is boosted by 6dB in floating point domain then converted into 16bit int. This will cause clipping if peak of foo.wav is higher than -6dBFS, but with --limiter you will have much less audible defect.
Note that non-linearity of --limiter is only capable of up to +9dBFS or so. Beyond that is simply hard clipped.

QAAC: discussion, questions, feature requests, etc.

Reply #646 –
Hello everybody,

With C.R.Helmrich and IgorC advices, I'm posting about a problematic intro for Apple/iTunes HE-AAC encoder.
Upload is here, anything under 80kbps is easily caught.
Just for info, sample is less than 5 seconds of well-known (?) Mr Probz's Waves remix by Robin Schulz.

Have a nice day,

        AiZ

QAAC: discussion, questions, feature requests, etc.

Reply #647 –
nu774, is there a particular reason the TVBR settings numbers are what they are? Can we use a "standard" set like I suggested on the other thread? For example: 0, 10, 20, 30, 40, 45, 50, 60, 70, 80, 90, 100, 110, 115, 125?

Thanks.

QAAC: discussion, questions, feature requests, etc.

Reply #648 –
I think these numbers are from Apple encoder.

QAAC: discussion, questions, feature requests, etc.

Reply #649 –
Quote from: lvqcl on
I think these numbers are from Apple encoder.

The range I know but even the precise one that the CLI selects?

For example:

Q5 - Q13 = 9

Q5 - Q13 I understand this is Apple but 9 is always picked because nu774 decided? Can he just change it to 10?