Skip to main content
Topic: QAAC: discussion, questions, feature requests, etc. (Read 401724 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1075
@nu774:

You once released this x64DLLs archive, 5 years ago ... maybe it's time to update it, if available (BTW, are there now even more supported formats in the meantime?), and possibly even for both bitnesses, a wholesome "lossless DLLs" archive? Just a suggestion, because ... I just had some minor efforts grabbing current 32 bit DLLs as well; still searching for an official source of libsndfile-1.dll (the one included in MSYS2 of MABS, v1.0.28, is not recognized, and erikd only releases sources).

Ah, wait, there are mega-nerd downloads. As installer. The included files work with qaac.

Attached my selection.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1076
(the one included in MSYS2 of MABS, v1.0.28, is not recognized, and erikd only releases sources).
As far as I can see, libsndfile-1.dll, libFLAC-8.dll and libwavpack-1.dll of MSYS2 all work fine with qaac.
If it didn't work for you, chances are that you didn't copy all of dependency libraries of libsndfile-1.dll
(You need libFLAC-8.dll, libogg-0.dll, libspeex1-dll, libvorbis-0.dll, libvorbisenc-2.dll, and libgcc_s_dw2-1.dll. Therefore, it's easier to just  add mingw32/mingw64 bin directory of MSYS2 to the PATH).

I understand that correcting every DLLs requires some efforts, but I also don't want to distribute my own copies of them, since I cannot promise you to keep them updated.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1077
Apparently there are also other software authors who do, like stax76 does for StaxRip-x64.

But another user reported in the German doom9/Gleitz board that he gets "ERROR: 193: CoreAudioToolbox.dll" when running "qaac64 --check" with the "makeportable" results of different more recent iTunes64 installers; only an older version from 2015 seems to work for him. Could you explain what this error is supposed to mean?

I don't get this error with the most recent iTunes64 installer version 12.7.1.14, running fine under Windows 7 SP1 x64.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1078
But another user reported in the German doom9/Gleitz board that he gets "ERROR: 193: CoreAudioToolbox.dll" when running "qaac64 --check" with the "makeportable" results of different more recent iTunes64 installers; only an older version from 2015 seems to work for him. Could you explain what this error is supposed to mean?
193 is ERROR_BAD_EXE_FORMAT.
This error happens when qaac64.exe can find only 32bit CoreAudio DLLs.
If the user has correctly copied QTfiles64 and still see that error, then I don't know.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1079
So it might have been a mistake of e.g. accidently copying from an extracted QTFiles directory into an existing QTFiles64 ... OK, surely a helpful analysis.
_

P.S.: Apparently the used makeportable batch was too old (in 2014, it could only handle 32-bit installers; the 2015 update supports iTunes 64-bit correctly).

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1080
From the Qaac wiki examples page https://github.com/nu774/qaac/wiki/Examples I refer to the artwork quote:

Quote
If you have folder.jpg (or something) in your encoding destination folder, and want to embed it to the result, use the setting like following:

-V 127 --artwork folder.jpg -o %d -

I have a folder.jpg in my source folder (surely the more likely scenario) and not in my target folder (as it will get embedded, right?). How is this possilbe? If not in Qaac I don't see it possible in Foobar.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1081
I have a folder.jpg in my source folder (surely the more likely scenario) and not in my target folder (as it will get embedded, right?). How is this possilbe? If not in Qaac I don't see it possible in Foobar.
You are right. In other words, the example is useless in a typical scenario.
Then you may ask, why the example is written that way?
Because, it's impossible to tell source folder path to the encoder unless foobar2000 support it (in the command line encoder setting).
From the encoder (qaac) perspective, it is executed in the destination folder and source PCM is coming via anonymous pipe from some unknown place. There's no way to know where the source file is, or even whether source is a file.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1082
I have a folder.jpg in my source folder (surely the more likely scenario) and not in my target folder (as it will get embedded, right?). How is this possilbe? If not in Qaac I don't see it possible in Foobar.
You are right. In other words, the example is useless in a typical scenario.
Then you may ask, why the example is written that way?
Because, it's impossible to tell source folder path to the encoder unless foobar2000 support it (in the command line encoder setting).
From the encoder (qaac) perspective, it is executed in the destination folder and source PCM is coming via anonymous pipe from some unknown place. There's no way to know where the source file is, or even whether source is a file.

I had a feeling you would say that. It looks like Foobar doesn't have the facility to embed the Artwork from the source folder.jpg file when converting. I'll have to continue my quest for an encoder for the job  :'(

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1083
Does the --threading option work?
It does not seem to do anything.
I use: qaac64 --threading -d o\  i\*.wav

There does not seem to be any use of multithreading. The CPU usage is as without the option.

I use version 2.64 and iTunes 12

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1084
IIRC, it means: Use a separate thread for the file access. So reading the input won't block the encoding. But the difference may hardly be measurable if the disk access is quite fast.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1085
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.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1086
New QAAC is posted;

  • Fixed a FLAC parser issue that picture tag gets lost when picture metadata comes before vorbis comments (thx to Matt Tyson).
  • Suppress console window title message when -s is specified.
  • Updated taglib.
https://sites.google.com/site/qaacpage/cabinet/qaac_2.65.zip

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1087
QAAC v2.66
Implemented look-ahead on --drc. The amount of look-ahead is the same as the attack time.

qaac_2.66.zip

A question to nu774: If qaac uses libsoxr64, does it mean it always uses SoX resampler to downrate to 48kwhen downsampling from hi-res sources?  I just want to know as I still prefer foo_dsp_resampler if not superfluous.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1088
A question to nu774: If qaac uses libsoxr64, does it mean it always uses SoX resampler to downrate to 48kwhen downsampling from hi-res sources?
Yes, it is used by default when libsoxr/libsoxr64 is present.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1089
Yes, it is used by default when libsoxr/libsoxr64 is present.

Good to know, can future qaac versions support more control of the process? (prevent clipping, quality factor, phase response, steep filter etc). I'm sure libsox supports all.

 

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1090
Good to know, can future qaac versions support more control of the process? (prevent clipping, quality factor, phase response, steep filter etc). I'm sure libsox supports all.
Of the resampler?
I don't think there's any practical needs for tweaking those options, so I'm not interested in it.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1091
I had the same issues with certain songs crashing my iPod (5th-gen) as previous posters ghostman6842 and tvks who both posted previously in the thread:

https://hydrogenaud.io/index.php/topic,85135.msg929625.html#msg929625

https://hydrogenaud.io/index.php/topic,85135.msg931801.html#msg931801

The crash (iPod black screen and reboot as soon as the track starts) is reliable and specific to only certain songs.  Some never crash, others always crash.

I was lucky enough to manage to track down the issue using old versions of QAAC - version 2.50 works, and versions 2.51, 2.59, and 2.66 all cause the crash.  In my case I am using 64-bit, with TVBR mode.

2.51 release notes mention a change to an avgBitrate field and a  "Encoding Params" tag, but I don't know which change is the actual cause of the problem.

https://sites.google.com/site/qaacpage/news/qaacrelease251


Re: QAAC: discussion, questions, feature requests, etc.

Reply #1092
paraquat, can you try the attached version?
This version writes non-zero value to the avgBitrate field like prior to version 2.51 ("Encoding Params" remains the same as 2.62) .

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1093
This version writes non-zero value to the avgBitrate field like prior to version 2.51 ("Encoding Params" remains the same as 2.62) .

Works without crashing.  Looks like it was the avgBitrate field causing the problem.  Thanks for the quick response!

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1094
Thanks, now released as 2.67.
The change in 2.51 was for standard compliance, but setting avgBitrate field to zero has never been popular anyway (for compatibility reasons).

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1095
Maybe a sensible default (non-complaint) and a command line parameter could be a plausible compromise?

Is there another program that can edit the tag easily? Or is that not the type of tag that can be easily edited?

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1096
I was surprised to find out today that QAAC tvbr 109 at 48kHz has a cut-off at a little bit below 22kHz. It was quite surprising because at 44.1 there's no cut-off, so I assumed same thing would apply to 48, only with slightly more bitrate. Reading posts from few pages back, it seems that this is a normal behaviour. Is there some way to get around it?

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1097
That's true. I would be curious what's the optimal preset for encoding 48kHz sampled sources onto AAC, to preserve most of the frequency range. Preset at 109 is already very high quality so I would expect to let in whole frequency range without perceivable quality loss.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1098
Ask Apple to change their encoder, I guess.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1099
That's true. I would be curious what's the optimal preset for encoding 48kHz sampled sources onto AAC, to preserve most of the frequency range. Preset at 109 is already very high quality so I would expect to let in whole frequency range without perceivable quality loss.
Even 127 has some kind of low-pass filter with 48kHz files, not as aggresive tho. I suspect that if 109 at 44.1 doesn't have a cut-off, with appropriately higher bitrate it should be also able to encode everything up to 24kHz. But if that's the decision Apple made, there's no much we can do.
I thought for a moment that maybe FDK or Nero could be able to do that, but they also use low-pass filters (and FDK allows no more than 20kHz, no matter what samplerate you choose).

 
SimplePortal 1.0.0 RC1 © 2008-2018