QAAC: discussion, questions, feature requests, etc., [originally a thread for a feature request] Options

[eahm]

nu774, did you test qaac with Windows 8? I am having problems converting.

CODE

Conversion failed: The encoder has terminated prematurely with code -1073741701 (0xC000007B); please re-check parameters

update1:
Is this Visual C++ again?

update2:
It works with the 32bit files inside the qaac ZIP, NOT with the 64bit.

This post has been edited by eahm: Oct 26 2012, 03:16

[nu774]

nu774, did you test qaac with Windows 8? I am having problems converting.

No, I haven't.

It works with the 32bit files inside the qaac ZIP, NOT with the 64bit.

Do you mean refalac64 still having problem?

[Anakunda]

Yes, eventually same AAC encoder of Apple is used, but that's all.
These two are completely different programs written by different authors. For example, qaac doesn't use QuickTime at all.

qtaacenc is updated also but not so frequently. Disregarding the factor which engine is which of them using does qtaacenc offer some advantage over qaac?

[nu774]

qtaacenc is updated also but not so frequently. Disregarding the factor which engine is which of them using does qtaacenc offer some advantage over qaac?

Well, it's much simpler and executable size is much smaller than qaac.

[sluggy]

[qaac] release 1.46 (refalac 0.57)

posted 3 hours ago by nu 774
Fixed a regression on 1.45: due to a subttle bug in option parsing code, --concat-cuesheet and --native-resampler were misinterpreted and not working.
Automatic RF64 output on -D (wav output), when file size is unknown or larger than 4G, and output is not connected to a pipe.
In these cases, at first "JUNK" chunk is written to where ds64 chunk goes, and if the file is actually beyond 4G limit at the end of writing, it is rewritten to ds64 chunk. Therefore, if it was actually smaller than 4G, JUNK chunk remains before "fmt " chunk. This is completely valid and legal in RIFF/WAV spec, but some software might get confused when seeing this.
Slight improvement on channel mapping code.
Additional search to mingw DLLs (libFLAC-8.dll and libwavpack-1.dll) When official win32 binaries are not found, these names are also searched.


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

[eahm]

It works with the 32bit files inside the qaac ZIP, NOT with the 64bit.

Do you mean refalac64 still having problem?

I only use qaac. I used to copy qaac.exe from the x86 and all the other files from x64 but it doesn't work with Windows 8. It works now when I copy every file from x86.

[nu774]

I only use qaac. I used to copy qaac.exe from the x86 and all the other files from x64 but it doesn't work with Windows 8. It works now when I copy every file from x86.

OK.
Actually it has nothing to do with Windows 8. Generally speaking, 32bit process can only load 32bit DLLs, and 64bit process can only load 64bit DLLs.
Therefore, qaac (32bit application) requires 32bit version of DLLs (in x86 folder).

In your case, probably you had MSVC runtime installed in your previous environment/OS. Therefore, qaac did work without installing MSVC runtime in the qaac zip archive.

[eahm]

Perfect thank you, for some stupid reason I thought qaac was x86 and x64.

[Anakunda]

QuickTime 7.7.3 was updated today releasing CoreAudio toolbox 7.9.8.2. I'm curious what was updated in this version?

[nu774]

QuickTime 7.7.3 was updated today releasing CoreAudio toolbox 7.9.8.2. I'm curious what was updated in this version?

As far as I can see, output of AAC encoder is identical with 7.9.8.1.

I also tested if ExtAudioFileRead() still crashes on HEv2 files, and now it doesn't.
However, even if I replaced CoreAudioToolbox.dll with 7.9.8.1, it doesn't crash. So I cannot reproduce the behavior on the previous version.
Maybe it might depend on other components... I don't know.

[eahm]

QuickTime 7.7.3 was updated today releasing CoreAudio toolbox 7.9.8.2. I'm curious what was updated in this version?

Sorry I just saw this post after I opened a new one for the 7.9.8.2.

This post has been edited by eahm: Nov 8 2012, 16:53

[sluggy]

[qaac] release 2.00 (refalac 1.00)
posted 41 minutes ago by nu 774
This is an experimental (might be unstable) release with many updates, so version was bumped up to 2.00.

Enabled MP3 decoding.
--concat + --adts now accepts multiple inputs with different sample format. Explained later.
Removed --concat-cuesheet, since it's mostly similar to --concat.
Added --no-dither, which turns off automatic dither on quantization.
-b now accepts arbitrary value in 2-32 range. -b32 for WAV output means float format. All other cases are integer.
-N(--normalize) now doesn't use temporary file if the input is seekable.
FLAC file with ID3v2 tag is now accepted (ID3 tag is just skipped and ignored).
Fix crash on reading TAK file with binary tag.
Improve ID3v2 tag handling.
Many refactoring of source code has been done.
Multiple format stream generated by --concat and --adts
Since this requires complete reset of the encoder, zero padding is added at the stream change point.

As far as I know, almost no software player on PC can continue to play such file after the stream format change. In my environment, Windows Media Player 12 is the only exception I know of.

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

[sluggy]

[qaac] release 2.01 (refalac 1.01)
posted Nov 16, 2012 4:31 AM by nu 774
Fixed a regression on 2.00: --threading was broken.

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

[Mix3dmessagez]

Hello all

Since the new update on quicktime albums encoded from cd would skip at a certain point in each song to the next song in the album for every song on the album.

This didn't happen to needledropped files or mp3 files, just new qt files encoded.

I used qaac to encode the flac files to alac does this fix that issue?

[deluge]

Hi, I have found possible bug in QAAC or in AppleApplicationSupport. I have encoded this sample: eig.flac --> http://www.hydrogenaudio.org/forums/index....st&p=622980 with QAAC 2.01 ( qaac.exe *.flac -c112 ) and CoreAudioToolbox 7.9.8.2 and result sample has realy bad distortion at the first 2 seconds.

[lvqcl]

Try CoreAudioToolbox 7.9.7.9 from iTunes 10.6.3.

But why do you want to use CBR?

[deluge]

I have used it for testing purposes only.

[nu774]

I quickly tested on the following set, and looks like only the combination of 7.9.8.2(or 7.9.8.1) and CBR 112k having that problem.
Anyway, it's interesting and thanks for sharing it -- although it's not an issue of qaac and there's nothing I can do for it.

7.9.8.2, -c112
7.9.8.2, -c96
7.9.8.2, -c128
7.9.8.2, -a112
7.9.8.2, -v112
7.9.7.9, -c112

[sluggy]

[qaac] release 2.03 (refalac 1.03)
posted 2 hours ago by nu 774
Fixed box layout of iTunes custom metadata (long tag). It was written as name-> mean -> data (should be mean -> name -> data).

This was a long standing bug, and I am somewhat surprised that no one has ever reported me of this. This should fix the interoperability problem with TagLib.

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

[Anakunda]

Should I worry the tags with previous qaac versions was somehow broken?

[eahm]

This was a long standing bug, and I am somewhat surprised that no one has ever reported me of this.

Because people know less than they actually think they do. I consider myself expert in many things but this is all new to me. I come here every day and get screamed for something I am sure I am doing right or for something I say that means absolutely nothing. It's a release of stress to see that you actually don't know everything and of course I know I don't but sometimes when you do and manage a lot of things like I do you think you know everything. Thanks to the people of the forum for waking me up every single day.

This post has been edited by eahm: Nov 27 2012, 15:02

[nu774]

Should I worry the tags with previous qaac versions was somehow broken?

If you are having no trouble concerning m4a tags so far, you don't have to worry about it.
Especially if you are running qaac from some front end such as fb2k and let it write the tags.

[nu774]

Because people know less than they actually think they do. I consider myself expert in many things but this is all new to me. I come here every day and get screamed for something I am sure I am doing right or for something I say that means absolutely nothing. It's a release of stress to see that you actually don't know everything and of course I know I don't but sometimes when you do and manage a lot of things like I do you think you know everything. Thanks to the people of the forum for waking me up every single day.

Touching tags afterwards by fb2k (for replaygain or something) is enough to fix the tag related issue. Therefore, I think it's just because most people are using fb2k with qaac.

I don't assume people take the trouble to look inside of MP4 container.
Since taglib shows some warnings when opening generated m4a file, it could be noticeable if someone tried it once.

[sluggy]

[qaac] release 2.04 (refalac 1.04)
posted an hour ago by nu 774
Fixed broken pipe input (regression on 2.00).

When feeding from pipe, there was always a chance that output from some arbitrary point become white noise like.

This was due to switch to lower level I/O routine on 2.00, which can result in "partial read" in case of pipe input. When it is still aligned to sample size boundary, it does no harm. However, when it is not aligned, the succeeding samples get completely out of sync, and result in white noise or something.

The possibility of this problem depends on how sender pushes audio to pipe, and sample size (16bit, 24bit, etc). I didn't notice it until today, but I could reproduce this using cat command as feeder.

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

[Anakunda]

Long awaited qaac 2.5 is out!

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

Sorry, 2.04 fix was flawed. Re-fixed it.

BTW, The problem on 2.00 was usually quite audible. If you are anxious about it, the apparent evidence of the bug is less number of samples compared to the original.

If you were using simply 16/32bit 2ch input, you might not have met any troubles so far (like me). In this case, sample size (in bytes) is multiple of 2, and probably there's less possibility of partial read breaking in the middle of sample boundary.