FFmbc 0.6-rc7 -ss -t don't output complete frames of audio about ffmbc HOT 7 CLOSED

Attaching screen capture of the differences shown in "Atom Inspector"

Hi Mark,

I think this has always been that way -t is not sample accurate.

I've tried using '-ss 2 -vframes 75' instead, but that doesn't give complete 
audio frames either.

Do you know if there is any method to get complete frames of audio?

Humm I'm not sure what you mean by "complete frames of audio". In PCM a 
complete frame is 1 sample. If now you think duration of pcm audio frame ~= 
duration of video frame.
There is no method currently, but it is an interesting idea.

Haha. Yes, that is an interesting different point of view.

Coming from a background of 20 years of Video Editing, I expect a frame of 
audio to be 1920 samples long (48K sampling/25 FPS).

As a video editor, if I am using a tool that lets me extract a subclip (using 
-ss and -t or -vframes) I expect to extract complete frames of video, and the 
corresponding samples of audio that completely and exactly match the complete 
duration of the video frames.

I can see how that is not possible with, for instance, mpeg2 audio frames who's 
timestamp start and end points do not necessarily exactly map to the start and 
end point timestamps of the video frames.

But, as a video editor, I've always worked with uncompressed video.

That thought lead me to an interesting experiment, excuse me while a ramble on 
for a while:

compare:

ffmbc -i primary.mov -ss 2 -vframes 75 -vcodec copy -acodec copy 1.mov

with:

ffmbc -i primary.mov -ss 2 -vframes 75 -vcodec copy -acodec pcm_s16le 1.mov

I find that consistently (for the same input file) that -acodec copy always 
gives me audio in lumps of 1024 samples until a small part of the last video 
frame has audio, then it stops (except for -vframes 1, where you get no audio 
at all).

My example of  -vframes 75 gives me 142336 samples (according to Atom 
Inspector).

75 frames of audio is 144000 samples (48000/25*75).
74 frames of audio is 142080
but I get 142336 samples, which is 139 * 1024
As it happens, 138 * 1024 = 141312, which is less than 142080

So 142336 samples is the first multiple of 1024 that completely satisfies 
142080 samples, but is 1664 samples too few to completely fill 75 frames of 
'PAL' video.


I find that consistently (for the same input file) that -acodec pcm_s16le 
always gives me audio in similar lumps of 1024 samples offset by 639 samples 
(except for -vframes 1, where you get no audio at all).

My example of  -vframes 75 gives me 142975 samples (according to Atom 
Inspector).

75 frames of audio is 144000 samples (48000/25*75).
74 frames of audio is 142080
but I get 142975 samples, which is 139 * 1024 + 639
As it happens, 138 * 1024 + 639 = 141951, which is less than 142080

So 142975 samples is the first multiple of 1024 + 639  that completely 
satisfies 142080 sample, but is 1025 samples too few to completely fill 75 
frames of 'PAL' video.

Wow - I wasn't expecting to see either 1024 or 639 in those calculations, but 
at least 1024 makes some sense!

Now, I know 'NTSC' audio is more complex with your crazy 1001, but it is a 
predictable sequence.

Anyway - rant over ;-)

Mark, I understand your rant, but let me correct you on one point:

"As a video editor, if I am using a tool that lets me extract a subclip (using 
-ss and -t or -vframes) I expect to extract complete frames of video, and the 
corresponding samples of audio that completely and exactly match the complete 
duration of the video frames."

FFmbc is _not_ a video editing tool. I have to redirect you to FCP or Media 
Composer for this, -ss and -t are convience tools but in no case guarantee what 
you seem to require.