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

[twinspex]

I have been producing my own modified version of REACT for use in ripping my CDs and have nearly finished the task. I wanted to be able to produce iTunes compatible and tagged .m4a files for individual tracks from the react image.cfg script having ripped to a one-big-file album image with cuefile. I managed to do this with the NeroAAc Encoder, acdir and atomic parsley. I then came across QTAACENC and QAAC which looked very promising as they allow use of the Quicktime dlls.

I totally failed to get either encoder working with ACDIR passing the split wave files into the encoder via STDIN in the analogous manner to that I successfully managed with the Nero encoder. No great loss though because I found QAAC alone can process a OBF wave image and associated cuefile into separate .m4a tracks - and it even tags the .m4a filees with the information taken from the cuefile. Fantastic!

I am left with a problem though. When processing from a cuefile QAAC outputs the track files in a format
tracknumber[space]tracktitle.m4a
and this cannot be changed. I like my files to be formatted thus:
tracknumber-tracktitle.m4a.
I think I am a competent enough batch file programmer to handle the necessary file rename (just! ), but the problem arises with various artists compilations. I really would like to use the naming format:
tracknumber-trackartist-tracktitle.m4a in such an instance.

I have looked online for a commandline based rename utility that would read the artist field from the embedded tag and alow me to use that field to rename the files QAAC produces. Unfortunately I haven't found one. (I know I could use something like mp3tag to do the job from a GUI later, but I would like to be able to do it as part of the REACT-based rip operation. I have looked at using the cuefile to extract track based wave files, which come out correctly named, and then to encode the track based wave files without using the cuefile. This results in no embedded tags and quite complicated scripting.)

I have no idea how difficult it would be to implement the output of m4a files to a specified filename format with QAAC cuefile processing, but if it is possible, please could the author please consider this as an enhancement request? I had a look at the source code but it is way beyond my skills to make myself an amended version! Thank you very much in advance.

(By the way I plan to use the NeroAAcTag utility to add cover art and albumArtist and compilation meta-user tags to the QAAC encoded .m4a files to finish the ripping task. I will be using OBF flac with embedded cover art and cuefile for archiving, and m4a for day to day usage).

Incidentally, if one uses QAAC cuesheet processing to produce .m4a files and then inspects the embedded tags with the neroAActage.exe -meta-list command on *.m4a I have noticed that the tools field may have a bug. On a three track CD single, using --ignorelength and --tvbr=125, the note of the tvbr setting is repeated one more time in the field for every successive track in the cuesheet. I don't hink this is a problem with the neroAActag.exe utility because the same repeated data is visible with the Audio Shell v1.3.5 utility! This problem is not a showstopper so far as I can see, but I haven't tried to do a sizable encoding task, and I wondered if it might cause a field overflow in such a situation.

example from Audio Shell v1..3.5 for the m4a file produced as track "03 Tracktitle" from the cuesheet:
Encoder: qaac 0.20, Quicktime 7.6.8 TVBR Quality 125, TVBR Quality 125, TVBR Quality 125,

I am using windows XP SP3 (up to date fixes), QAAC 0.20 and Quicktime 7.6.8 The quality setting was merely an experiment.

To bring a verbose post to an end. Thank you for producing this utility. I will find a workaround if you can't help.

[Larson]

I found a bug with QAAC when converting to tvbr with -q value 1 (since there's a bug with latest quicktime version and -q 2 as far as I've read). For instance with TVBR 113 (around 256 kbps) the resulting bitrate is much lower than it should be. There's no problem with CVBR instead.