broadcast .wav wrapper getting truncated on import - Windows Media Foundation conversion questions

Question

I'm having issues with mp2 files that have been wrapped as .wav files with riff/bwf metadata. The files are normally an hour or so in length, and we need to process a simple conversion from 32 bit float to 16 bit for playback. On Windows 7 and older versions of Adobe CC, this was no problem at all. However, when using Windows 10 and Adobe CC, the files no longer are opened as .wav files, and are instead "Read using Windows Media Foundation" and truncating the last few seconds. Alternatively, Adobe Media Encoder won't take the files at all, identifying that the source compression type is not supported.

What's happening in Audition is that the file is losing the last few seconds of content.

For a file that is 1:06:15.000 (and able to be opened in older Adobe versions and Windows 7) shows up as 1:06:10.633 in Windows 10 1803 and Adobe CC 2018/2019.

I've already been able to come up with a workaround by using the older Adobe Audition and Windows 7 to properly convert the files to .wav without metadata, or VLC to convert, after which CC Audition 2018/19 reads the correct file time.

The really strange bit is that this same 1:06:15.000 file, when played in Windows Media Player, will play back the entire file with no truncation, but the duration is 1:06:10.633. The file appears to be playing at a slightly increased speed to accommodate for the lack of 5 seconds, but of course, WMP shows the playback speed at 100%. It seems that Windows Media Foundation is reading the file differently and providing the incorrect duration length, and Audition takes this length (but not the modified playback speed) and as such is truncating the end of the audio.

Is there any way to have Audition not utilize Windows Media Foundation on file import? Or what other ways could potentially problematic .wav wrappers be read and converted in Audition without truncating the end of the audio clip?

johnsmarkmizzou · Accepted Answer

[UPDATE 11/20/2018]Digging into things a bit more, and it appears that while the playback speed in Windows Media Player/Groove music is indeed different than the playback speed of Adobe, that's not the biggest issue.The actual timecode/clocks used between Adobe and Windows Media are drastically different when reading .mp2 files encoded using Hindenburg. There is a variation of a couple of seconds after just 20 minutes of playback. I have the same file playing in both WMP and Adobe Audition, and while the playback showed a slight amount of sync issues (a few frames) over a 20 minute period, the clock for WMP was 2 seconds slow. Over the course of an hour long clip, the WMP clock would show a reduced duration, but still play the entire file. As Audition AND Media Encoder are pushing the files to Windows Media Foundation to initially read the files, the duration is reported by WMP. Audition is taking this duration and assigning it to the track, but with the "faster" Adobe clock, Audition will cut off playback prematurely.Windows appears to be having issues with the duration of files encoded using Hindenburg, and reports the wrong duration, cutting off a few seconds. The clock used in WMP or Groove is then fluid, and is "slow" compared to an actual clock. When Adobe tries to open the file, it pitches the file to the Windows API, grabs the incorrect duration, but does not provide the floating clock speed to allow playback of the entire file, and instead cuts of the file at the incorrect duration listed.I'm not sure if this occurs with other encoders, but I have been in contact with the makers of Hindenburg.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.