You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have discovered several hundred WAVE files with multiple fmt chunks (see this example). It seems that an editing software used by our institution renders WAVE files with several headers as a way to divide the file into sections (!!). Besides length, sometimes the headers even include different sample rates or bit depths --which can make an audio player play the file at the wrong speed.
Naturally, this seems to confuse various readers: values for e.g length appear differently in ffprobe, mediaInfo and exiftool.
This issue is admittedly an outlier, but... Is there a way to fix it? Even just adding markers at the positions of the original headers would be helpful.
The text was updated successfully, but these errors were encountered:
Naturally, this seems to confuse various readers: values for e.g length appear differently in ffprobe, mediaInfo and exiftool.
MediaInfo output is fixed now, you have the 2 durations, sample rates and bit depths displayed, as well as the total duration.
In BWF MetaEdit, theses files are currently rejected (unsupported), we could easily show the full trace (currently parsing stops at the 1st error so the 2nd fmt), it would be lot of work to support edition of such file.
Is there a way to fix it?
We could merge both "tracks" into 1 (upscaling if not the same sample rates or bit depths), add a cue sheet with a marker, but theses files have other opaque metadata chunks ("aux " and "DAVD"), they could become incoherent.
Also not a small task.
I have discovered several hundred WAVE files with multiple fmt chunks (see this example). It seems that an editing software used by our institution renders WAVE files with several headers as a way to divide the file into sections (!!). Besides length, sometimes the headers even include different sample rates or bit depths --which can make an audio player play the file at the wrong speed.
Naturally, this seems to confuse various readers: values for e.g length appear differently in ffprobe, mediaInfo and exiftool.
This issue is admittedly an outlier, but... Is there a way to fix it? Even just adding markers at the positions of the original headers would be helpful.
The text was updated successfully, but these errors were encountered: