M4A file locked by Reaper even with audio device closed

DrTT · 03-22-2019, 10:29 AM

Dear all,

this is a variation of a bug reported by godly in Nov. 2017.

I am using the current version 5.973 of Reaper-64bit on Windows 10.

Several tracks in a project of mine contain externally generated MP3
files, one track has an m4a audio file (also externally generated as a
reference for comparing the other tracks to).

I have enabled the following flags in Reaper:
- Close audio device when stopped and application is inactive
- Close audio device when stopped and active

Using SysInternal's handle reveals that - when inactive - Reaper keeps
no handles on the mp3 files, but it definitely keeps the handle on the
m4a file making recreation of that file impossible.

Is this still a (known?) problem?

Best regards
DrTT

mschnell · 03-23-2019, 12:37 AM

IMHO it does make sense that Reaper would lock the files loaded in tracks. Reaper creates "Peak" files for any of them and these would be out of sync if some other application would modify the audio file while Reaper is running.

I don't see what the audio device could have any influence on this.

-Michael

DrTT · 03-23-2019, 09:20 AM

Hi Michael,

when the player is not active there is no need to keep exclusive access to external media files. When those files are rendered by external programs, the workflow is severely obstructed by that locking, because you always have to close Reaper first to do that rendering.

Obviously MP3 files are now handled correctly (according to my opinion), but M4A files are not. Notice also that when the player is inactive and Reaper has lost focus, external media files - at least MP3s - are labelled as "OFFLINE" in the track window.

Also the peak calculation can be redone when Reaper finds out that some file has changed externally. Other programs can cope with that (and even Reaper does that for some file types), so this should be no principal problem.

Best regards,
DrTT

Justin · 03-23-2019, 03:06 PM

Yeah, m4a files use the video decoders (if available), and video files are not closed when inactive (because usually re-opening the video files again is incredibly slow).... so live with it I guess?

mschnell · 03-24-2019, 01:29 AM

Thanks for the clarification !
-Michael

DrTT · 03-27-2019, 02:33 PM

Hello Justin,

thanks for commenting personally!
Your explanation is comprehensible, but nevertheless it is a pity that an audio file with just a different codec is not handled like other audio files with simpler formats.
I have to compare internal audio tracks with an externally generated AAC audio loaded into a reference track in Reaper. The current limitation means that I have to close Reaper whenever I do an external regeneration.
Any chance to either check whether audio files are involved (instead of videos) and handle those like other audio files or otherwise to have an option that tells that a file reload should _always_ be done when the file modification date has changed?

Best regards
DrTT

Justin · 03-28-2019, 07:35 PM

The problem is that the opening of the files via ffmpeg/vlc is generally an order of magnitude than a native format, so setting it offline would almost always cause performance issues. Can you use another format?

mschnell · 03-28-2019, 11:14 PM

Quote:

Originally Posted by Justin

The problem is that the opening of the files via ffmpeg/vlc is generally an order of magnitude than a native format, so setting it offline would almost always cause performance issues.

Maybe a configuration option could be desirable for some...
-Michael

Justin · 03-29-2019, 11:18 AM

Quote:

Originally Posted by mschnell

Maybe a configuration option could be desirable for some...
-Michael

Fair enough, next dev build will have that

DrTT · 03-29-2019, 12:10 PM

Dear all,

unfortunately I need some private lesson on Reaper's architecture: Some audio formats seem to be handled by internal or at least efficient external codecs provided by Reaper, others are processed by VLC/ffmpeg or system codecs?

My use case is that I generate AAC tracks embedded in some MP4 video, but tune the generation parameters by trying them out in Reaper before. Ideally the generated audio should match the audio in Reaper.

Of course, I could also generate MP3 files for Reaper import by the external process, but this takes significant additional time. Hence I'm trading in the closing and reopening time of Reaper for additional external generation time.

Video in Reaper is not at all important for me, so if an option for "offlining" M4A files (or all external audio files) was provided, this would be fantastic.

Is there a broad estimation what the time penalty is when an offlined file is reopened by Reaper?

Best regards
DrTT

nofish · 03-29-2019, 03:59 PM

It's available for testing now in current dev build (v5.973+dev0329a).

(To get pre/dev Reaper versions see:
https://forum.cockos.com/showthread.php?t=22836)

DrTT · 03-30-2019, 08:54 AM

Dear developers,

thanks a lot, it works perfectly in the dev-version! This absolutely helps me in my workflow.

Two questions/observations:

- According to Sysinternals "handle" and with the option disabled, Reaper keeps _two_ handles on the M4A file. Is this intended?

- As Justin has pointed out (and the option also mentions this), the reopening of videos is _slow_. Any hints what this means in practice (e.g. in seconds)? In my use case the regeneration of the waveform in Reaper takes about 1/4s after getting focus.

Best regards and thanks for your effort!
DrTT

nofish · 03-30-2019, 11:24 AM

Comments / questions etc. about stuff related to pre / dev versions should be posted in the pre-release forum in the related thread (here in this case).

Quote:

Please post any comments and especially bug reports about pre-release builds in this forum. It's best to keep discussion of features and bugs in the main forums, and on outside forums, limited to the current release build, and talk about the new stuff here.

https://forum.cockos.com/showthread.php?t=22836

Meant as a friendly heads up (seeing that you're rather new here).

DrTT · 03-30-2019, 02:42 PM

Hello nofish,

Quote:

Originally Posted by nofish

Please post any comments and especially bug reports about pre-release builds in ... Meant as a friendly heads up (seeing that you're rather new here).

Thanks for the information!

My comments were not meant specific for the dev version, but anyway I have posted the question/remarks in the appropriate thread.

Best regards
DrTT