Meaning of duration
Suppose you have recorded an Opus stream with -copyts. Then ffprobe -v error -show_entries format=start_time,duration -- recording.opus shows non-zero start_time and possibly huge duration that does not reflect to the file size. I think you get the actual duration of the recording by subtracting start_time from the given duration. Is that intentional and by definition? I tried recording some MP3 streams with and without -copyts, and start_time is then always small non-zero number (0.011995). Why is that? I have not tried all formats, but apparently they vary in this respect.
Am 30.12.22 um 14:25 schrieb Jarno Suni:
Suppose you have recorded an Opus stream with -copyts. Then
ffprobe -v error -show_entries format=start_time,duration -- recording.opus
shows non-zero start_time and possibly huge duration that does not reflect to the file size.
the days where duration and filesize are hard connected are long gone, even for MP3 everybody with soime basic knowledge is using VBR because it saves 16% stoarge while keep identical or even better quality
On Fri, Dec 30, 2022 at 3:34 PM Reindl Harald <h.reindl@thelounge.net> wrote:
the days where duration and filesize are hard connected are long gone, even for MP3 everybody with soime basic knowledge is using VBR because it saves 16% stoarge while keep identical or even better quality
Yes I know, but the duration tag(?) may tell e.g. 500h even if the file has 15s audio (at least in case of Opus recording recorded with "-copyts").
On 12/30/2022 5:34 AM, Reindl Harald wrote:
the days where duration and filesize are hard connected are long gone,
Hard connected, no; but a 3 hour duration on a 2mb file is probably wrong. I've found that duration metadata is often incorrect unless file was re-coded, and even then it can be suspect. If you want an _exact_ duration, count the frames and divide by the rate (assuming a constant rate). Later, z!
Am 30.12.22 um 17:30 schrieb Carl Zwanzig:
On 12/30/2022 5:34 AM, Reindl Harald wrote:
the days where duration and filesize are hard connected are long gone,
Hard connected, no; but a 3 hour duration on a 2mb file is probably wrong.
I've found that duration metadata is often incorrect unless file was re-coded, and even then it can be suspect. If you want an _exact_ duration, count the frames and divide by the rate (assuming a constant rate)
and since it's not constant these days that won't work for audio-files anything relies on avg-bitrate
On 12/30/2022 8:36 AM, Reindl Harald wrote:
and since it's not constant these days that won't work for audio-files anything relies on avg-bitrate
frame (sample) rate should still be constant even while encoded bit-rate isn't (or are are there now encodings that vary the sample rate?). 'course, one can simply "play" the file and time it :D. z!
Suppose you have recorded an Opus stream with -copyts. Then
ffprobe -v error -show_entries format=start_time,duration -- recording.opus
shows non-zero start_time and possibly huge duration that does not reflect to the file size. I think you get the actual duration of the recording by subtracting start_time from the given duration. Is that intentional and by definition?
I tried recording some MP3 streams with and without -copyts, and start_time is then always small non-zero number (0.011995). Why is that? I have not tried all formats, but apparently they vary in this respect. Try using this together with -copyts
-start_at_zero When used with copyts, shift input timestamps so they start at zero. This means that using e.g. |-ss 50| will make output timestamps start at 50 seconds, regardless of what timestamp the input file started at.
On Fri, Dec 30, 2022 at 6:54 PM Ferdi Scholten <ferdi@sttc-nlp.nl> wrote:
Try using this together with -copyts
-start_at_zero
When used with copyts, shift input timestamps so they start at zero.
I do not see what is the use of using -copyts, if that resets the timestamps anyway with -start_at_zero. I want to be able to seek using the original timestamps.
participants (4)
-
Carl Zwanzig -
Ferdi Scholten -
Jarno Suni -
Reindl Harald