Clip length mystery - longer clips getting cut short in live 10

[sqwj]

I'm using live 10 to process longer (30 min- 2 hours) hour spoken word files, and I'm having a consistent issue where the last 1-5 minutes is consistently getting cut short.

For example, I just dragged a 16MB, 29:10, file into an audio track. When ableton 10 finished processing it, the clip was only 28:40 (not warped). It's not just a timestamp issue, when I listen to the audio, there is missing content at the end. I haven't noticed whether the length of missing audio is proportional to the length of the audio, but it appears to be a random amount of missing audio generally.

These are usually files recorded with zoom h4n recorders, usually via an xlr out from a mixer.
I have also noticed that vlc and foobar tend inaccurately determine the length of many of these files as well -- usually they 'think' the file is longer than it is. So this same file loads into vlc as a 31:51 file and loads into foobar as a 39:48 file. In both of these applications, when I try to play a portion of the file beyond the true 29:10 of audio, it skips to next track or stops playback.

I can't help but think this is a metadata/zoom encoder issue, but I can't find any answers in the vlc/foobar/zoom support realm.
Any thoughts Solving this issue would scratch an itch that's been really getting to me.
Thanks!

[oblique strategies]

I've used long soundfiles for many years with many versions of Live as well & have never experienced the issue you describe.

You've probably already tried this but have you verified the length of the clip by dragging the End Marker in Clip View to the right?

Good luck. Please post the reason & hopefully fix if/when you find it. Thanks!

[chrk]

In what file format are the files recorded on the H4n, do they contain marks?

According to the current H4n Pro manual, p. 49

WAV files recorded in STEREO/4CH/STAMINA mode
comply with BWF (Broadcast Wave Format) and
include marks and creation dates

That may not go down well with some audio software including Live.

Try importing them into Audacity, for a free and open source editor it's got a couple of tricks up its sleeve for file format conversion.

[Tarekith]

That is very strange. I use a H4n myself and have never run into this issue. I'd try contacting Zoom and see what they say, if only because you're seeing this with different apps so it doesn't appear to be app related.

[jestermgee]

I too use a H4n and have not had this issue but I am guessing you are recording to an encoded MP3 and not a WAV? I’d personally record to Wav on the recorder then convert to MP3 with software as it could be an issue with the way it encodes a file over time.

[sqwj]

Thanks to all for the thoughtful replies!

In what file format are the files recorded on the H4n, do they contain marks?
According to the current H4n Pro manual, p. 49

WAV files recorded in STEREO/4CH/STAMINA mode
comply with BWF (Broadcast Wave Format) and
include marks and creation dates

That may not go down well with some audio software including Live.
Try importing them into Audacity, for a free and open source editor it's got a couple of tricks up its sleeve for file format conversion.

These files are all recorded as MP3s. I'm not really sure why, but my colleagues have always recorded in MP3 - probably for faster transfer and saving on archive storage space- I've not questioned it until now.

Your comment about Audacity got me thinking. Before I investigated file conversion, I decided to just import one of the files to audacity, then export it without any processing and compare the 2 files. The mysterious file issues were gone! Comparing these 2 files side by side in ableton, foobar, and windows properties, the 'audacity re-rendered' version is consistently being analyzed at the correct length. When I brought the audacity re-rendered version into ableton for post-processing, the clip was the correct length and was complete in terms of actual content. Thus, the processed export from ableton seems to be the desired end product for my application.

I've just gotten to work, so I've only done this with one file so far. While this isn't really a 'solve', it seems like it will be a manageable workaround until I stumble onto the actual problem causing this issue. I may need to comb through the zoom documentation and perhaps check the settings on our recorders.

[chymera]

What bitrate are the MP3 files that are being recorded? If they are less than 320, try upping the quality to 320 and see if the same issue occurs.

[chrk]

What bitrate are the MP3 files that are being recorded?

My guess: VBR. MP3 has no header field for lenght, with fixed bitrate the players can calculate the lenght from sample rate and number of samples, for VBR they guesstimate from the effective bitrate of a portion of the file.

I'd never record anything that's going to be processed further to MP3 anyway, and it's not even a great archiving format. What's lost in mp3 compression remains lost.