Calculating audio track duration in seconds

[ClementNerma]

Hi there!

I'm currently trying to compute the duration of a given Track. From what I understand, the following works:

track.codec_params.time_base?.calc_time(track.codec_params.n_frames?) // Gives a `Time` value

Is that right?

In case these values aren't available (e.g. formats with variable sample width such as MPEG or Vorbis), I understand the entire audio track needs to be read in order to determine the duration from the sum of all samples, right?

How do I achieve this? I have the loop that can get me a set of AudioBufferRef, but I don't know how to get an actual duration from it.

How can I compute it? Thanks in advance for your help :)

[pdeljanov]

Hi there!

I'm currently trying to compute the duration of a given Track. From what I understand, the following works:

track.codec_params.time_base?.calc_time(track.codec_params.n_frames?) // Gives a `Time` value

Is that right?

Yup!

In case these values aren't available (e.g. formats with variable sample width such as MPEG or Vorbis), I understand the entire audio track needs to be read in order to determine the duration from the sum of all samples, right?

We're getting better with this over time for formats that make it hard.

For MP3, Symphonia will look for a Xing/Info tag and use that to populate n_frames. If there is no Xing/Info tag, or the codec is MP1/2, Symphonia will try to estimate the duration based on bitrate and file size.

For OGG, if the source is seekable we should provide you an accurate n_frames.

Of course, counting samples will always be accurate!

How do I achieve this? I have the loop that can get me a set of AudioBufferRef, but I don't know how to get an actual duration from it.

How can I compute it? Thanks in advance for your help :)

You don't actually need to decode.

You can accumulate the value of Packet::dur. This would give you the total number of decoded samples. However, if you enable gapless playback, you will want to subtract Packet::trim_start and Packet::trim_end from Packet::dur first to get the real duration.

[ClementNerma]

Thanks for your answer!

If there is no Xing/Info tag, or the codec is MP1/2, Symphonia will try to estimate the duration based on bitrate and file size.

What is the precision of this estimate? I absolutely need to have a precision of +/- 1 second for my current use case.

You can accumulate the value of Packet::dur. This would give you the total number of decoded samples. However, if you enable gapless playback, you will want to subtract Packet::trim_start and Packet::trim_end from Packet::dur first to get the real duration.

Does this method work with formats like MP3? If each sample can have a different bitrate, getting the total number of samples won't help to compute the total duration?

Also I don't use symphonia for playback, I only use it to extract metadata from audio files, so I suppose I don't need to substract trim_start and trim_end?

[pdeljanov]

If there is no Xing/Info tag, or the codec is MP1/2, Symphonia will try to estimate the duration based on bitrate and file size.

What is the precision of this estimate? I absolutely need to have a precision of +/- 1 second for my current use case.

It should be a sample accurate length in the vast majority of cases. However, since it is just a piece of metadata up to the encoder to specify correctly, it could also be completely wrong!

You can accumulate the value of Packet::dur. This would give you the total number of decoded samples. However, if you enable gapless playback, you will want to subtract Packet::trim_start and Packet::trim_end from Packet::dur first to get the real duration.

Does this method work with formats like MP3? If each sample can have a different bitrate, getting the total number of samples won't help to compute the total duration?

The method will work for all formats. However, for VBR MP3 it becomes a bit less accurate than counting samples. For VBR, Symphonia averages multiple MPEG audio frames to get the average bitrate, then uses that for the estimate.

Also I don't use symphonia for playback, I only use it to extract metadata from audio files, so I suppose I don't need to substract trim_start and trim_end?

MP3 encoders add padding samples that need to be trimmed off by a decoder. So it'll be more accurate by about +/- 50ms if you subtract the trim amounts. If you count samples, the decoder will do the trimming for you so you don't need to do anything. However, if you just use the raw timing information from the Packet you will need to take it into account yourself.

[ClementNerma]

I don't really get what you mean, concretely what would the code look like if I want to count samples to measure precise duration?

And how far from reality would be the duration computed by the packets only (using packet.dur)?

[pdeljanov]

The solutions I proposed in the previous message: decoding and counting samples vs. just summing p.dur - (p.trim_start + p.trim_end) for each packet (p), will produce identical results.

These two methods are the most accurate. Both require minimal modifications of the standard decode loop from the getting started example.

However, there are two things to note:

1. That value will likely differ from n_frames for MP3 files that are VBR encoded.
2. The value may change depending on if gapless playback is enabled or not.

Since your desired accuracy is +/-1 second, I recommend using n_frames if it's provided. If it is not (let us know if you have cases where it's not), you can fallback to the summing method to avoid the cost of decoding. This should be good for your application!

You should also enable gapless playback, see here.

[ClementNerma]

Thanks for your answer.

I don't get why I should enable gapless playback - concretely how is it useful for summing durations?

[pdeljanov]

Thanks for your answer.

I don't get why I should enable gapless playback - concretely how is it useful for summing durations?

Strictly speaking, the padding ("gaps") added by the decoder is a consequence of the manner in which most lossy codecs work. Since these samples are undesirable, we usually enable gapless mode to trim them off. More concretely, enabling gapless mode more faithfully decodes the original length of the audio.

I'm going to move this to discussion since this is question about digital audio in general.