nu774
commented
7 years ago I tested fdkaac and found funny thing. When --ignorelength option are present I'm getting strange block of date in the end of the file. Duration changed from 00:24:29.696 (70545407 samples) to 00:25:04.491 (72215551 samples), none of original data was modified.
This is not strange at all and to be expected. --ignorelength literally tells fdkaac to ignore the length of data chunk in the WAV file where PCM is stored. When specified, every byte until the end of file is regarded as the payload of data chunk, thus regarded as PCM. Then what if your wav file contains some other chunk such as metadata after the data chunk? What you have observed in the above picture is this. In short, non-PCM data after PCM is treated as PCM, yielding garbage like this.
In other words, this is NOT an option you should be casually setting without knowing it's meaning.
This option is mainly meant to be used for piping. Other use case is invalid WAV file larger than 4GB (limit of the WAV spec). In such a case feeding program often cannot write valid data chunk length. Therefore, we need a way to ignore it. (Chunk length has to be written before data, which means program has to either know the exact length of data beforehand, or has to seek back after all data has been written, which is impossible in case of piping)
I tested fdkaac and found funny thing. When --ignorelength option are present I'm getting strange block of date in the end of the file. Duration changed from 00:24:29.696 (70545407 samples) to 00:25:04.491 (72215551 samples), none of original data was modified.
Why this happening? Seems like this is libfdk-aac related.
Without --ignorelength I'm not getting this block. Length is same as source wav (00:24:29.696).
Output of fdkaac with --ignorelength:
Output of fdkaac without --ignorelength:
fdkaac 0.6.3, libfdk-aac 3.4.22, MacOS 10.10.5 Encoding parameters:
fdkaac (-I) -f 2 -m 5 -o "${1%.*}.aac" "$1"