(Master Feature) Add --retain-markers to rdimport(1) and dropboxes #383
Conversation
|
What happens if multiple cuts exist when using |
|
The Cut Start and Cut End markers are not preserved when using the following command line: Perhaps it would be useful to retain them if Auto Trim is disabled (--autotrim-level=0)? |
|
Another good question. My first thought was, this could/should only happen once, since all the cuts will be deleted after the first run. I choose to use the meta data from the next scheduled cut using RDCart::selectCut(). I know what I will be doing is let the dropbox load the cut and then edit the markers since any cuts from existing dropboxes will not have any markers. |
Yes, that info should have been retained. I'll get that fixed per your recommendation. |
|
Is I'm thinking that perhaps we need a simple rule for this that is not dependent cut dayparting --e.g. always use the markers from the newest (most recently imported) cut. |
|
That's an option. I couldn't really think of which was the best way to handle multiple cuts was. I was considering logging an error/warning if there was more than 1 cut. If there's more than 1 cut we either have to make a best guess (which will probably be wrong) or skip it and let the user remove the extra cuts. It's really a chicken/egg problem of which came first, the cart or the dropbox? Also, speaking of chicken/egg, now that the PR with database 307 has been merged, I'll update the this PR to 308. |
Update database to version 308 Conflicts: ChangeLog utils/rddbmgr/updateschema.cpp
Make a best guess --e.g. 'use markers from the most recently imported cut'-- and make sure that that's documented clearly in the man page. That way, everyone knows what to expect.
If |
|
Interesting... I made the So the plan is to use markers from the most recently imported cut unless One other question while we're on the subject, does |
I think we're operating on a misunderstanding here. Suppose there are multiple cuts in the targeted cart before any cuts are deleted? That was the case I was asking about.
Why would that be an error? Simply use the same rule (apply markers from most-recently-imported cut).
No, because in that case, a new cart is created, which is by definition empty initially. So actually, the |
|
Ok. I think I have it now. PR updated. |
|
Alas, yet another issue... Create a cart, import a long-ish piece of audio into it (say, 4:00 long). Set the segue markers out near the end (say, around 3:58 or so). Now, do We need some sanity checks here. If just an end marker is beyond the end of the imported audio, move it back to the end audio position. If both the start and end markers are beyond the end, then remove both markers (with the exception of 'Cut Start' and 'Cut End', in which case the best we can do is put them at the start and end of the actual audio). Some warnings to stderr and/or syslog would probably be a Good Idea too. |
|
This feature was based on the assumption that the length of audio imported was constant. If that isn't a valid assumption then we have to do something along the lines of what you recommend. If it is a valid assumption, then I feel the thing to do is retain the markers as-is and log a warning. |
|
Assumption or not, it's something that's going to be broken sooner or later; through user ignorance, malice or simple inadvertance. When that happens, we have to be able to cope with it. |
|
What happens when the log player bumps into a cut where the markers are out of bounds? Maybe we should handle out of bounds markers there and not modify them in the database? |
|
No cut that exists within Rivendell should have 'out-of-bounds' marker data. This is one of the basic invariants of the database design. Any process that imports 'external' marker data --e.g. rdimport processing timer data from a CartChunk -- must perform validation on that data to ensure that no 'out-of-bounds' conditions exist before writing such to the database. You can see an example of how such validation works in the The situation here of course is 'backwards' from the usual case -- it's not the marker data that is changing, but rather the underlying audio to which the marker data is being applied. |
|
Sounds good. I'm thinking about back-peddling on this feature since it seems like any tremor in the force will cause bad things to happen. I'll put the validation in and see how it looks. |
|
I have not tested this yet, but if you could look at Also, what do you think about a method to load all the markers into variables with a single SQL statement and another method to write them all with a single SQL statement. The way all of these markers are handled seems expensive. |
That's putting it quite charitably. :) Yes, the whole business of marker validation grew by accretion over time, which is the major reason why it's the diffuse mess that it is right now. I agree that centralizing this validation logic is a Good Idea. I'm thinking of something along the lines of:
bool RDWaveData::validateMarkers(int len=-1)
Where You can populate an instance of My goal is to have the new |
That sounds like a great idea! |
|
Committed in [master d024d27]. At this moment, |
|
I still have more work to do. Please ignore these latest commits. |
|
I've run into a problem that I may not have time to look at for a couple of days. The problem may be with the audio editor in rdlibrary(1), not with this PR, so I'm going to push the changes for this PR. I'm using the test tone cart for testing. When that cart is imported with rdimport(1), it says the length of the cut is 10069. I then go into "Edit Markers" and do nothing but click "Save". When I import the same audio file, the end marker has been changed from 10069 to 10082 causing an out-of-bounds return from validateMarkers() since the end marker is now beyond the length. |
Adds the ability for rdimport(1) and dropboxes to import new audio to an existing cart without overwriting previous markers.
I'm not sure how to handle multiple PRs with database changes, so I'm making them all the next number, 307.