|
|
|
05-28-2020, 05:27 AM
|
#1
|
Human being with feelings
Join Date: Oct 2006
Location: swing on the spiral of our divinity
Posts: 2,242
|
Update items source preferred position (used by BWF)
the BWF source position tag is a life saver when moving files between DAWs and other Reaper projects. Can we get an action to update an items preferred source position information so that when we make edits inside Reaper and move files around, that we can get the latest and great information baked in very easily?
|
|
|
05-28-2020, 09:42 AM
|
#2
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
+1 this would be very useful and prevent having to create an additional audio file using glue.
|
|
|
05-28-2020, 10:15 AM
|
#3
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Ahh nice FR, +1 from me. Hadn't thought of that one.
|
|
|
05-30-2020, 03:22 AM
|
#4
|
Human being with feelings
Join Date: Oct 2007
Location: Lincoln, UK
Posts: 7,924
|
Quote:
Originally Posted by Klangfarben
+1 this would be very useful and prevent having to create an additional audio file using glue.
|
Isn’t that what glue is for?
It’s quite an easy edit to do, even in script, but it is a file edit, it changes the file content. If you’re going to do this, you ought to change the BEXT Content Creator at least, and better still note that it’s been amended in the user field. It’s better practice to glue and create a new file.
As REAPER isn’t fully metadata savvy for wav files yet, an edit would mean the loss of data like the iXML chunk and the channel function and naming, associated track function, naming and file names, and filename history information. This is data vital to some workflows, and we should be careful about making it easy to “edit the negatives” so to speak when it’s this destructive. Even the REAPER method of writing cue points into a wav file involves a render rather than an edit -you don’t lose your original.
There is a good argument for easy amendment of cue data, metadata tagged on the end of the wav file as bookmarks, but “Samples Since Midnight” (your Source Preferred Position) is a pre-audio-data positioned chunk that users expect not to be changed in the original file.
I’d love it if this could be done properly -“glueing” in place and updating the metadata in the copy; storing the old “source preferred position” and filename in an updated iXML metadata chunk along with the other metadata -reminding you that this is one file in a multitrack poly set maybe, and asking if you want to update the set?
Sorry if this is a bit wordy, but I’d urge caution going in this direction, especially when we can “glue” the file in place and achieve the same thing.
>
|
|
|
05-30-2020, 07:46 AM
|
#5
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
You wouldn't lose all the iXML or any of the other bext info. You would just be updating one specific line of the bext chunk.
Also, with glue you are creating an entirely new file. So if you want to just update the timecode start, you are doubling the number of files. This is both inefficient and unnecessary when you can instead just update one line of the bext chunk.
Don't create monsters in the closet when there are none.
|
|
|
05-30-2020, 07:53 AM
|
#6
|
Human being with feelings
Join Date: Mar 2007
Posts: 3,978
|
Quote:
Originally Posted by Klangfarben
...<snip>
Also, with glue you are creating an entirely new file. So if you want to just update the timecode start, you are doubling the number of files. This is both inefficient and unnecessary when you can instead just update one line of the bext chunk.
<snip>...
|
But then it is destructive to original file. And that does not meet with Reaper's non-destructive behavior, does it?? !!!
|
|
|
05-30-2020, 08:05 AM
|
#7
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by akademie
But then it is destructive to original file. And that does not meet with Reaper's non-destructive behavior, does it?? !!!
|
I'm not sure what your point is. Glue always creates a new file with audio items and appends the name with "-glue"
With OPs feature request, if you wanted to change the timecode start of 100 files, you would have 100 updated files. With the current Reaper behavior you would now have 200 files. The first is clearly more efficient than the second.
|
|
|
05-30-2020, 08:19 AM
|
#8
|
Human being with feelings
Join Date: Mar 2007
Posts: 3,978
|
Quote:
Originally Posted by Klangfarben
I'm not sure what your point is. Glue always creates a new file with audio items and appends the name with "-glue"
With OPs feature request, if you wanted to change the timecode start of 100 files, you would have 100 updated files. With the current Reaper behavior you would now have 200 files. The first is clearly more efficient than the second.
|
I only point out that it is the Reaper's way, I mean to not touch the original files, nothing more.
It is more efficient to keep 100 orig files and change few bytes here and there instead of creating 100 new ones, for sure. But it is not the way Reaper behaves. And to be truth, thanks God for that, even if we need to deal with lots of new files which takes time and space.
|
|
|
05-30-2020, 08:35 AM
|
#9
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by akademie
I only point out that it is the Reaper's way, I mean to not touch the original files, nothing more.
It is more efficient to keep 100 orig files and change few bytes here and there instead of creating 100 new ones, for sure. But it is not the way Reaper behaves. And to be truth, thanks God for that, even if we need to deal with lots of new files which takes time and space.
|
In that case, shouldn't Normalize in Reaper also create a new audio file? It doesn't.
|
|
|
05-30-2020, 09:32 AM
|
#10
|
Human being with feelings
Join Date: Mar 2007
Posts: 3,978
|
Quote:
Originally Posted by Klangfarben
In that case, shouldn't Normalize in Reaper also create a new audio file? It doesn't.
|
Normalize only sets volume parameter of the item, doesn't it? The original "physical" file stays the same and playback level property is set (for the item in the project). No file is harmed
|
|
|
05-30-2020, 02:53 PM
|
#11
|
Human being with feelings
Join Date: Oct 2007
Location: Lincoln, UK
Posts: 7,924
|
Quote:
Originally Posted by Klangfarben
You wouldn't lose all the iXML or any of the other bext info. You would just be updating one specific line of the bext chunk.
Also, with glue you are creating an entirely new file. So if you want to just update the timecode start, you are doubling the number of files. This is both inefficient and unnecessary when you can instead just update one line of the bext chunk.
Don't create monsters in the closet when there are none.
|
Yes, I understand, I said it was easy with script. I’ve written code to read and write, BEXT, iXML, AXML and cue chunks in wav files and I’ve done what you are suggesting on my own files in test scenarios. I prefer to create a new file, or create a copy and rename the original “_old”.
You are amending the contents of a file created by “A” using “B”, but leaving the documentation saying it was created by “A” and no further notes. It’s just bad professional workflow, you update the metadata if you change things.
I appreciate this might seem nonsense to a home user, but some post-production automated processes rely on that metadata. When you’re handing many thousands of audio files for a production, and that’s only one of many on the schedule, you need that documentation in those files to manage it.
If you want to do that at home with a metadata editor, that’s up to you, but you can’t ask a professional application like REAPER to do it without the user being aware of its destructive aspect. The monster in the closet is the loss of traceability and metadata. If that’s not a problem, then delete your originals after glueing.
I didn’t come here for an argument, I’m just trying to explain why I don’t think it is good practice and I don’t think the Devs will do it.
>
|
|
|
05-30-2020, 06:11 PM
|
#12
|
Human being with feelings
Join Date: Oct 2006
Location: swing on the spiral of our divinity
Posts: 2,242
|
I only care about the non-destructive angle when it comes to things that will affect how audio sounds. Meta-data of file formats is something that is commonly updated and amended.
I'm not saying this should be automatic behaviour obviously. It would be a user selected option. In which case I'd expect the user to understand the ramifications of their choice.
For my needs I want to update this positional information so that when I hand files off to colleagues and they want to assemble a new project with those files either in Reaper or in Studio One, that they can get up and running very quickly by just moving the item to it's original origin position.
|
|
|
05-31-2020, 12:28 AM
|
#13
|
Human being with feelings
Join Date: Oct 2007
Location: Lincoln, UK
Posts: 7,924
|
In which case, glueing the items in their new position should do this. If you glue BWF items, the new files will contain an updated “source position” that corresponds to their ruler position.
>
|
|
|
04-09-2021, 12:52 AM
|
#14
|
Human being with feelings
Join Date: Apr 2017
Location: Los Angeles
Posts: 64
|
Have there been any developments here?
|
|
|
04-11-2021, 12:42 AM
|
#15
|
Human being with feelings
Join Date: May 2017
Posts: 3,202
|
I have to agree with planetnine on this. If you have 23 separate items sourced from the original wav file, and moved from their original positions, which of those should reflect the correct BWF start time? Once an item is moved, the link to BWF start time is (and should be) lost.
If only the original wav item, unmoved, is at the BWF Start time, then that leaves 22 copies whose start times are incorrect. Now if you move the original, or trim the beginning, you want to have it rewrite the BWF start time? So what happens if you tell Reaper to move one of the item copies or fragments to the BWF start time? Does it jump to where the original wav start time is? And what happens if you discover a positioning error and want to restart by moving it to its preferred start position, but the start time in the BWF has been overwritten because you made time edits on it? You'd be SOL...
It seems to me to be a wrongheaded approach.
It does make sense to allow using the BWF Start time for importing a whole wave to a track, but with the ability Reaper has to use fragments of the same file as separate items in different places on the timeline, adding this would expose a nest of dragons.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:54 PM.
|