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 676311 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

QAAC: discussion, questions, feature requests, etc.

Reply #200
AAC has less holes in high freq, also are you a bat?


No not a bat  does "less holes in high freq" mean a worse encode quality? I think the hard cutoff at ~19.5kHz by AAC is no good but not sure about that.
I'm curious if iTunes does their encodes using the same QuickTime library or something else. Looked at iTunes original track which otherwise was a noticeably higher bitrate but there wasnot such a hard cutoff. Finally I'm not too impressed by the spectral of this TVBR.

QAAC: discussion, questions, feature requests, etc.

Reply #201
AAC has less holes in high freq, also are you a bat?


No not a bat  does "less holes in high freq" mean a worse encode quality? I think the hard cutoff at ~19.5kHz by AAC is no good but not sure about that.
I'm curious if iTunes does their encodes using the same QuickTime library or something else. Looked at iTunes original track which otherwise was a noticeably higher bitrate but there wasnot such a hard cutoff. Finally I'm not too impressed by the spectral of this TVBR.


I can hear up to 17khz, so this 19.5khz is more than enough for me. Holes/darker parts means less energy.

QAAC: discussion, questions, feature requests, etc.

Reply #202
"A higher cutoff frequency" is not the only criterion for "subjectively better quality"; that would rather be a general "less annoying loss". What if the high frequency range prevents the codec from preserving quality in lower, more audible ranges?

A more variable frequency spectrum may be a sign for a more "optimistic" psycho-acoustic model; this is neither a guarantee for better or worse quality on its own. Just a proof for a different algorithm. It may sound more or less lossy, depending on many factors.

If subjective impression could be measured and quantized more directly than in a "mass ABX test", we could have an objective quality metric.

QAAC: discussion, questions, feature requests, etc.

Reply #203
Vorbis achieves higher frequencies but probably at cost of worse reproduction in higher range.
So I guess it's not possible to say if QAAC model is better or worse.

QAAC: discussion, questions, feature requests, etc.

Reply #204
Is it normal that encoding 5.1 audio in Multi-threading mode is slower than single threading?
Total time used by Multi-thread encoding (either 2 or 4 instances at the same time) is slower than consecutive single-thread encoding everytime I've tried. And total CPU usage is quite a bit low during multi-thread encoding with enough ram and hdd power left. This doesn't happen with stereo audio, with 2.0 tracks CPU usage skyrockets to full 50 or 100% and the work's blazing fast.

Simply put, one by one work is faster for 5.1 audio. Kinda weird? (My system is i5-2540m Sandybridge, Win7 32bit)

QAAC: discussion, questions, feature requests, etc.

Reply #205
QuickTime/CoreAudio encoder itself always works on a single thread.
When --threading option of qaac is set, encoder and decoder/DSP run on two different threads (one thread for each).
Therefore, --threading will give you faster speed only when you do some heavy work on decoder/DSP side.




QAAC: discussion, questions, feature requests, etc.

Reply #206
[qaac] release 1.40 (refalac 0.51)
posted 5 hours ago by nu 774  [ updated 4 hours ago ]
Update libsoxrate to 0.30 (merged update on rate effect of SoX: Speed up on down sampling).

Due to ABI change on libsoxrate.dll, new qaac/refalac is incompatible with older libsoxrate.dll versions.

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

Thanks for the update.

QAAC: discussion, questions, feature requests, etc.

Reply #207
I'm using qaac 1.39 and am having random problems with encoding FLAC to AAC.  I see 26x+ speed (I saw sustained 40x for a bit before it slowed down) most of the time, but on some files the encoder will progress at a sluggish ~1.2 to ~1.7x speed, but the real kicker is the resulting file is silence.  This is completely random and an unknown number of retries / accessing data from a different part of the disk after X minutes (that's a really long time) will "fix" the problem and let qaac actually encode something that's not silence.  Foobar2000 can play the FLAC file fine, of course, and the FLAC file is not corrupted.

Anyone know what's going on?  Non-ASCII/long filenames/locations, FLAC tags, and inside/outside archives don't seem to be the problem after some testing.

QAAC: discussion, questions, feature requests, etc.

Reply #208
I'm using qaac 1.39 and am having random problems with encoding FLAC to AAC.  I see 26x+ speed (I saw sustained 40x for a bit before it slowed down) most of the time, but on some files the encoder will progress at a sluggish ~1.2 to ~1.7x speed, but the real kicker is the resulting file is silence.  This is completely random and an unknown number of retries / accessing data from a different part of the disk after X minutes (that's a really long time) will "fix" the problem and let qaac actually encode something that's not silence.  Foobar2000 can play the FLAC file fine, of course, and the FLAC file is not corrupted.

Anyone know what's going on?  Non-ASCII/long filenames/locations, FLAC tags, and inside/outside archives don't seem to be the problem after some testing.

Apparently, this slow speed silence bug has something to do with using --lowpass 19700?  (I'm only using this for TVBR 100+... from a glance at the spectrographs it doesn't seem to change the distribution of bits at all, just imposes a hard wall which saves a couple hundred KB per song.)

Is this a known bug of qaac and/or Core Audio?


QAAC: discussion, questions, feature requests, etc.

Reply #210
It's impossible to fix a bug (if any) if I cannot reproduce it.
If you can reproduce it, please share the problematic file and write precise step to reproduce it (command line, etc).

QAAC: discussion, questions, feature requests, etc.

Reply #211
It's impossible to fix a bug (if any) if I cannot reproduce it.
If you can reproduce it, please share the problematic file and write precise step to reproduce it (command line, etc).


It's not a file - it's every file, FLAC or WAV, any location.  When the bug kicks in and I let the process finish encoding at ~2x instead of 40-50x, the resulting file is ~22 kbps of the correct length, but complete silence.  (instead of ~200 kbps)  As I said, after an unknown number of playback / disk reading changes, the said files can be encoded properly again.  It's completely random but affects every single file.  I've now even had it encode the first 2 tracks of an album as slow silence (with proper length), but successfully encode the other 10 tracks of the album.

my foobar2000 arguments are
Code: [Select]
-V 109 --lowpass 19700 - -o %d


I don't think this bug happens when I use -V 91 and don't set a lowpass (the default lowpass for -91 is lower than 19.7).  So my thoughts are it's the lowpass.

QAAC: discussion, questions, feature requests, etc.

Reply #212
I don't think this bug happens when I use -V 91 and don't set a lowpass (the default lowpass for -91 is lower than 19.7).  So my thoughts are it's the lowpass.


Your command line isnot producing any faulty output. Check if qaac using proper libsoxrate dll. Also try append --ignorelength to command line if encoding through PIPE.

QAAC: discussion, questions, feature requests, etc.

Reply #213
I don't think this bug happens when I use -V 91 and don't set a lowpass (the default lowpass for -91 is lower than 19.7).  So my thoughts are it's the lowpass.


Your command line isnot producing any faulty output. Check if qaac using proper libsoxrate dll. Also try append --ignorelength to command line if encoding through PIPE.

If I try a wrong libsoxrate.dll, qaac crashes after 1 second and won't encode anything at all.

What does "encoding through PIPE" mean?  A filepath containing the "|" aka flacs inside zip/rar packages?

QAAC: discussion, questions, feature requests, etc.

Reply #214
Using the command line interpreter and the "pipe symbol" (|) is one way to make a pipe, a connected redirection of the output of one application (>) into the input of another application (<). It can also be built with OS functions.

"Pipe aware" CLI applications usually support a single dash (-) as placeholder for standard input and output file handles instead of file names for disk files. In this case, they "print the output file content to the standard output" instead of using disk file operations; this requires specific options under Windows to support correct binary output.

STDIN = file handle 0 (usually assigned to the console, keyboard)
STDOUT = file handle 1 (usually assigned to the console, monitor)
STDERR = file handle 2 (usually assigned to the console, monitor)

The standard error handle can be redirected too, using its number 2 preceding the redirector (e.g. '2>'), which can be useful to store error messages into a log file.

QAAC: discussion, questions, feature requests, etc.

Reply #215
@nu774
Is there a technical reason why e.g. MP3 files are not supported as input for QAAC?
I thought that libsndfile does support MP3...

QAAC: discussion, questions, feature requests, etc.

Reply #216
Why recoding a worse format which already suffers from psychoacoustic loss?


QAAC: discussion, questions, feature requests, etc.

Reply #218
Why recoding a worse format which already suffers from psychoacoustic loss?


E.g. to recode an MP3 audiobook @ 192 kbps / multiple files to an iPod compatible M4B file with chapters @ 48 kbps...


QAAC: discussion, questions, feature requests, etc.

Reply #220
HydrogenAudio has higher ideological standards.

A workaround could be piping {lame --decode *.mp3 - | qaac -i ... -o *.m4a -}.

QAAC: discussion, questions, feature requests, etc.

Reply #221
A workaround could be piping {lame --decode *.mp3 - | qaac -i ... -o *.m4a -}.

I've already considered that, but I couldn't find a way to use piping in combination with QAAC's --concat switch.
So I ended up with first converting all the MP3 stuff to WAV and then running "QAAC --concat *.wav -o audiobook.m4b" which uses more time and temp disc space than neccessary...

QAAC: discussion, questions, feature requests, etc.

Reply #222
@nu774
Is there a technical reason why e.g. MP3 files are not supported as input for QAAC?
I thought that libsndfile does support MP3...

AFAIK libsndfile doesn't support MP3, but CoreAudio does. As far as using CoreAudio built-in decoder, license/patent would not matter.
I don't want to support MP3 input mainly because it's not important at all for a command line AAC encoder, while implementing it is a pain for me (handling of encoder delays, etc..) .

QAAC: discussion, questions, feature requests, etc.

Reply #223
I don't want to support MP3 input (...) implementing it is a pain for me (handling of encoder delays, etc..) .

I can perfectly understand your point of view.
And (unless another work-around for my "single audiobook conversion problem" surfaces, I'll stick to my intermediate WAV solution...

Or, does anyone have a solution (command line tool for Windows) to concat multiple m4a files to a single m4b file with chapter marks at file boundaries?

QAAC: discussion, questions, feature requests, etc.

Reply #224
SITUATION: I ripped all of my CDs to FLAC about 4 years ago using EAC.  I felt like FLAC was the best option at the time and still may be however I have recently moved to iPhones (wife's decision) with iOS 5.1.1 so syncing FLAC files to the iPhone using foobar2000 is not possible.

PROPOSED SOLUTION: I am thinking about converting my FLAC to ALAC using foobar2000 and qaac so I can use iTunes to sync the files to the iPhone.

CONCERN: It is my understanding that prior to November 2011, ALAC was a closed format and ALAC encoders were reverse engineered.

QUESTIONS: Is qaac based on the reverse engineered ALAC encoder or is it based on the "official" specification?  I would be disappointed if I converted my FLAC collection to an "unofficial" ALAC implementation only to have something incompatible about the files at some point in the future.  I am not technical enough to understand some of the specifications but I know I want my files archived in some lossless format.

OTHER CONSIDERATIONS: I realize that I could use MediaMonkey to sync the files but that may only last until Apple changes something in their software to break syncing with MediaMonkey.  Additionally, I don't think that the free version of MediaMonkey does transcoding on the fly.  I know I could also just convert my FLAC to mp3 and keep both copies of the files but maintaining two versions of the same file sounds like torture to me.