The actual duration of the first file must be reduced to 1328128 - 2112 =
1326016 for decoding, because the last frame received from FFmpeg ends at
Is this inconsistency caused by iTunes or by FFmpeg? As a workaround I need
to reduce the duration of all AAC files by their start_time (if start_time >
0) to avoid running into issues when decoding affected files.
Re: Wrong duration of AAC files encoded by iTunes 12.3.0
Tested again as requested with ffprobe from git HEAD. The actual duration_ts
calculated from the first and last frames is (1327104 + 1024) - 2112 =
1326016 instead of 1328128 as reported for the stream.
Please also notice that the first frame of the file encoded with iTunes
12.3.0 contains only 960 instead of 1024 samples which is consistent with
the actual duration_ts of 1326016.
Let's try again and please remember not to top-post here
and not to cut the console output.
You are writing in the subject about "wrong duration": How
can I reproduce "wrong duration"? Please try not to answer
with a formula but more with something like "'ffmpeg -i input'
reports a duration of 90 seconds but the input file is actually
100 seconds" or "'ffmpeg -i input output' produces a file with
Allow me to repeat: Is the issue reproducible with "ffmpeg",
the command line tool or are other tools (like ffprobe) needed