DTS and AC-3 playback regression in ffmpeg-based players

j7n · 19th August 2025, 09:44

DTS and AC-3 in practice always have constant bitrate unless two streams are stitched together. However, FFMPEG and all players downstream of it (Foobar, MPC-HC, others) carefully parse the stream or give an incorrect playback time estimation. Seeking in long files is inaccurate or slow. Open bitrate DTS streams cannot be seeked (Open means that the Transmission Bitrate is not indicated). DTS has the discrepancy between Transmission Bitrate and actual bitrate, such as 1536 vs 1509 kbit/s, the difference of which grows with long tracks.

Old players and the updated Gabest source filter provided by the MPC-BE fork work correctly.

I think this should be fixed without requiring muxing into Matroska or another container because the problem is rather simple.

I made a pseudo-VBR streams alternating between two frame sizes linked in [2] displaying the behavior. AC-3 actually shows the average, meaning that the entire file was walked to determine it.

1. https://www.reddit.com/r/foobar2000/..._my_dts_files/

2. https://hydrogenaudio.org/index.php/topic,128242.0.html

3. https://trac.ffmpeg.org/ticket/10675

tebasuna51 · 19th August 2025, 22:01

Only one of your samples have a strange but correct headers/frames:

Code:

File: D:\Temp\Ptebak\shape1235.dts
Size: 4630528 bytes
----------------------------------------- First Frame Info
CRC present .................: 0 
Number PCM Sample Blocks ..BL: 32 (1024 samples/frame)
Primary Frame Byte Size ...FR: 3584 
Audio Channel Arrangement .CH: 9 (5 C + L + R + SL + SR)
Core Audio Samp. Frequency SR: 8 (44100 Hz)
Transmission Bit Rate .......: 22 (1411 Kb/s)
Embedded Down Mix Enabled ...: 0
Embedded Dynamic Range Flag .: 0
Embedded Time Stamp Flag ....: 0
Auxiliary Data Flag .........: 0
Mastered in HDCD format .....: 0
Extension Audio Flags .....EX: 0 (Channel Extension XCh)
Extended Coding Flag ........: 0
Audio Sync Word Insert. Flag : 1
Low Frequency Effects Flag LF: 2 (Present, interpolation factor 64)
Predictor History Flag Switch: 1
Multirate Interpolator Switch: 0
Encoder Software Revision .BS: 7 (Current)
Copy History ................: 1 (Definition deliberately omitted)
Source PCM Resolution .......: 2 (20 bits)
Front Sum/Difference Flag ...: 0
Surrounds Sum/Difference Flag: 0
Dialog Normalization Par. .DN: -0 dB
----------------------------------------- Revised DTS Info
Total Frames / SubF: 1292 / 0
Bitrate Core / Avg.: 1234 / 1234 Kb/s
Duration ..........: 30000 ms (0 h. 0 m. 30.000 s.)
------------------------------------------------- End Info

The rest are fake dts with wrong data.

The difference between Transmission bitrate (1411 Kb/s) and real bitrate (1234 Kb/s) is well know for all correct players and ffmpeg can't be blamed for that.

About ac3 I can't see the problem, of course concatenate two streams with different bitrate is not allowed.

j7n · 20th August 2025, 05:00

Most bitrates encoded by DTS are slightly lower than the transmission bitrate. It doesn't have to be DTS-CD. 1536 is the bandwidth of stereo @ 48 kHz. But DTS is encoded at only 1509.75 kbit/s on DVD. When you have one music album, the difference in playback duration adds up to around a minute. It is possible to get the actual bitrate by looking at the frame size.

Gabest filter vs MPC-HC:
https://i.imgur.com/nq0jOBX.png

The problem with AC-3 is that seeking is slow if your computer is not ultra modern. It is not very noticeable with a regular duration song. If you load an AC-3 file with a cue sheet, and try to jump to the end, there will be a pause. Instead of jumping to the particular address, it goes through the entire file.

19th August 2025, 09:44	#1 \| Link
j7n Registered User Join Date: Apr 2006 Posts: 185	DTS and AC-3 playback regression in ffmpeg-based players DTS and AC-3 in practice always have constant bitrate unless two streams are stitched together. However, FFMPEG and all players downstream of it (Foobar, MPC-HC, others) carefully parse the stream or give an incorrect playback time estimation. Seeking in long files is inaccurate or slow. Open bitrate DTS streams cannot be seeked (Open means that the Transmission Bitrate is not indicated). DTS has the discrepancy between Transmission Bitrate and actual bitrate, such as 1536 vs 1509 kbit/s, the difference of which grows with long tracks. Old players and the updated Gabest source filter provided by the MPC-BE fork work correctly. I think this should be fixed without requiring muxing into Matroska or another container because the problem is rather simple. I made a pseudo-VBR streams alternating between two frame sizes linked in [2] displaying the behavior. AC-3 actually shows the average, meaning that the entire file was walked to determine it. 1. https://www.reddit.com/r/foobar2000/..._my_dts_files/ 2. https://hydrogenaudio.org/index.php/topic,128242.0.html 3. https://trac.ffmpeg.org/ticket/10675

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

20th August 2025, 05:00	#3 \| Link
j7n Registered User Join Date: Apr 2006 Posts: 185	Most bitrates encoded by DTS are slightly lower than the transmission bitrate. It doesn't have to be DTS-CD. 1536 is the bandwidth of stereo @ 48 kHz. But DTS is encoded at only 1509.75 kbit/s on DVD. When you have one music album, the difference in playback duration adds up to around a minute. It is possible to get the actual bitrate by looking at the frame size. Gabest filter vs MPC-HC: https://i.imgur.com/nq0jOBX.png The problem with AC-3 is that seeking is slow if your computer is not ultra modern. It is not very noticeable with a regular duration song. If you load an AC-3 file with a cue sheet, and try to jump to the end, there will be a pause. Instead of jumping to the particular address, it goes through the entire file.