If you are on windows you'll want to use QAAC to encode AAC: http://www.hydrogenaudio.org/forums/index....showtopic=85135MMX and SSE2 are just processor extensions that can be used for faster encoding (which is pretty pointless for iTunes since last time I checked it was single-threaded...).
I thought I remembered QAAC being a recommended encoder in my reading last year, but I'm wondering if it just uses the same encoding process at iTunes. Does it? What are the benefits of using QAAC vs. iTunes, other than that it provides a way to encode AAC outside iTunes? I assume it would give me the option of using TVBR, but what is the benefit of TVBR over CVBR? Thanks for the replies.
And as for the 128 kbps (mono)/256 kbps (stereo) bitrate, in your opinion, is that overkill for lossy music; or is it worth going for a higher bitrate? I know it all depends on the listener and the amount of storage space, but I would just like opinions and ideas. If I remember right, 256 kbps is on the high end of the bitrate spectrum for lossy audio, but I've never compared music at various bitrates. I do want to make sure that I can get the best possible quality that I can fit on my iPhone, so I want to start with a bitrate that is considered to be very good quality lossy audio, convert some albums to AAC with that bitrate setting, estimate how many albums I could fit on my iPhone at that setting, and then lower it if necessary. Is 256 kbps a reasonable place to start, or should I go with one of the other presets in iTunes and/or a custom bitrate setting?Lastly, are there any reasons why I might be better off encoding outside of iTunes? For example, it sounds like I would need to use something other than iTunes if I want to use TVBR encoding (but as of now I don't know the benefit of TVBR over CVBR). I plan to use FFMPEG with EAC to immediately encode my rips to ALAC as described here: http://wiki.hydrogenaudio.org/index.php?title=EAC_and_ALAC , and then I was thinking I would just drag the ALAC files into iTunes, right-click on them, and create AAC versions of them. Would I be missing out on anything by not using some other program to encode to AAC? Would I benefit by using something like foobar2000 to pass some command-line arguments to the encoder? If so, what arguments do you recommend?
In my opinion LAME -V5 is a good place to start for portable usage. Try to ABX. Keep in mind it will be much more difficult to spot encoding artifacts in noisy environments. As long as you have lossles files, you can always transcode with foobar if you change your mind.If you are dead set on bitrates around 256kbps, again I would just stick with LAME for ease of use. Sounds to me Apple AAC is a pain to work with. If you really must have AAC, why not use Nero--again for ease of use.
In the example in the Word document, these arguments are actually passed to cmd.exe, which passes them to qaac.exe. I'm curious to know why they can't just be passed directly to QAAC from EAC.
Did I use the correct syntax for QAAC in the above examples? Any other suggestions? One thing I am specifically wondering about is the use of the slash in the commands for the "track" and "disk" options.
I plan to only rip to ALAC in EAC, and then use foobar2000 to transcode to AAC with QAAC. By default, does QAAC include tags, lyrics, and album art from the source in the output? Or will I have to specify those tags in the arguments from foobar2000?
My final question: Is TVBR 110 quality a good place to start for someone who wants to err on the side of quality over file size? Would anything higher be overkill for someone who plans to put music on their iPhone? I just chose 110 as the quality because that is what the author uses in the "random example from [his] setup."
(Personally I'm too lazy to setup EAC for tagging. I'd rather just use cuesheets, or use CueRipper).
How does one use cue sheets for tagging, and how is that easier than setting up EAC for tagging?
Because most tagging information cannot be found on the CD itself, and must be downloaded from a database or manually entered, correct? (Or is that not true?)
Maybe I should try CUERipper, but the most important thing to me is to get accurate rips.
So from an accuracy standpoint, is the only real difference between the two the number of times they re-read when errors are detected?
In addition, CUERipper comes with CUETools Database compatibility built-in. I read that this database provides the "ability not only to detect, but also correct small amounts of errors that occurred in the ripping process". Would anyone be able to comment on this feature? I like the idea that I can somehow perfect my imperfect rips, but what are the chances that the database provides data from an imperfect rip and screws up my own rip?