Quote from: gaekwad2 on 05 February, 2010, 01:52:28 PM... Besides, it's not always strong enough to prevent clipping anyway...I too have noticed that.For instance here are three samples from my archive.The encoding settingsFLAC: -8M4A: QT --tvbr 62 --highestMP4: Nero -q 0.41MP3: Lame -V5
... Besides, it's not always strong enough to prevent clipping anyway...
I'm having a problem with qtaacenc that I haven't discovered the cause of. With long title tags (>130 chars or so), or perhaps long pathnames, it drops ALL tags although it encodes the filename correctly. Has anyone encountered a problem of tags not being written by qtaacenc? (The max length for a non-lyrics tag in itunes should be 255 chars).The outfilename is being passed as unicode. the infile is -
Is there a way to have the foobar command line encoder embed the full size album art (if it exists in the file being converted) just like XLD does?
the length bug is due to Quicktime apparently,the same happens to me if I rip a song in iTunes and has a long title,it gets cut. I sent a few emails about it to Apple iTunes Feedback but with no luck and it looks like it's by design. Anyway if you use Dbpoweramp through CLI encoder and let dbpoweramp write the tags,the problem doesn't seem to happen.
1) The length of the input/output path should be less than MAX_PATH (260 characters).2) I don't know well about the special syntax, but at least it cannot be used with qtaacenc.3) No clue. qtaacenc always handles command-line arguments as unicode.
Does this update contain some improvements?
The update also offers a setting that enables automatic conversion to 128 kbit/s AAC when songs are transferred to iPods or iPhones.
and something else: as I hear (ABX log needed?) that bult-in resampler introduces some artifacts (or noise)
Nao, is it possible from qtaacenc's side?
Can you upload a sample file where this effect is noticeable?