Skip to main content ↑ ↓
Topic: QAAC: discussion, questions, feature requests, etc. (Read 450581 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 –
Quote from: LigH on
(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 –
Quote from: LigH on
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 –
Quote from: ManekiNeko on
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 –
Quote from: nu774 on
Quote from: ManekiNeko on
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 –
Quote from: nu774 on
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 –
Quote from: Anakunda on
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 –
Quote from: nu774 on
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 –
Quote from: Anakunda on
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 –
Quote from: nu774 on
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 –
Quote from: Anakunda on
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-2020