Hi! First of all, thanks for fre:ac — it's a great tool and I use it regularly.
I wanted to report a behavior I encountered when working with an MP4 file that contains multiple internal audio tracks (in my case, 9 tracks from a screen recording with alternating "Sharing Started" / "Sharing Stopped" segments).
Steps to reproduce:
- Open an MP4 with multiple audio streams in fre:ac
- Select all tracks and use the join/combine option to export as a single MP3
- Open the resulting MP3 in another application (e.g., VLC, Audacity, a mobile player)
Expected behavior:
The resulting MP3 should be recognized as a single continuous audio file with the full combined duration.
Actual behavior:
The output file plays correctly in fre:ac itself, but other applications only detect and play the first track's worth of audio. The rest of the content is present in the file but effectively invisible to other players.
Root cause (hypothesis):
It appears the join operation performs a simple frame-level concatenation without recalculating the global MP3 headers (Xing/LAME header, total frame count, duration metadata). As a result, the header of the output file still reflects only the first segment's duration, causing compliant decoders to stop there.
For comparison, running ffmpeg -f concat -safe 0 -i list.txt -c:a libmp3lame -q:a 2 output.mp3 produces a correctly joined file that all applications recognize.
Suggested fix:
After concatenation, regenerate the Xing/Info header with the correct total frame count and duration, or use a re-encode pass to produce a properly formed output file.
Environment:
- fre:ac (latest stable)
- Windows
- Input: MP4 with 9 audio streams
- Output format: MP3
Happy to provide a sample file or additional details if helpful. Thanks for the amazing work! 🙌
Hi! First of all, thanks for fre:ac — it's a great tool and I use it regularly.
I wanted to report a behavior I encountered when working with an MP4 file that contains multiple internal audio tracks (in my case, 9 tracks from a screen recording with alternating "Sharing Started" / "Sharing Stopped" segments).
Steps to reproduce:
Expected behavior:
The resulting MP3 should be recognized as a single continuous audio file with the full combined duration.
Actual behavior:
The output file plays correctly in fre:ac itself, but other applications only detect and play the first track's worth of audio. The rest of the content is present in the file but effectively invisible to other players.
Root cause (hypothesis):
It appears the join operation performs a simple frame-level concatenation without recalculating the global MP3 headers (Xing/LAME header, total frame count, duration metadata). As a result, the header of the output file still reflects only the first segment's duration, causing compliant decoders to stop there.
For comparison, running
ffmpeg -f concat -safe 0 -i list.txt -c:a libmp3lame -q:a 2 output.mp3produces a correctly joined file that all applications recognize.Suggested fix:
After concatenation, regenerate the Xing/Info header with the correct total frame count and duration, or use a re-encode pass to produce a properly formed output file.
Environment:
Happy to provide a sample file or additional details if helpful. Thanks for the amazing work! 🙌