Assemble EDL to pro...
 
Notifications
Clear all

Assemble EDL to protools

10 Posts
3 Users
0 Likes
233 Views
Posts: 6
Customer
Topic starter
Joined: 4 years ago

Could it be available to assemble an EDL to pro tools within a BH database?

Thanks in advance

9 Replies
Posts: 566
Admin
Joined: 5 years ago

Hey!

Explain a bit more.   
I'm a bit confused cuz BH is not a linear DAW so please explain a bit more.  😉

thx!

Steve

Reply
Posts: 6
Customer
Topic starter
Joined: 4 years ago

Many thanks, Steve

 

Pretty much as Kraken does.

Short

https://www.youtube.com/watch?v=0obWE2Ycr-4

Long

https://www.youtube.com/watch?v=sRKg_aNLn7Y

 

Take care

DC

 

 

Reply
Posts: 566
Admin
Joined: 5 years ago

Why not just use Kraken if it does what you want already? hehe  😉

I keep adding more feature for dialog editors in each version slowly but Kraken is a whole another type of tool/animal and if I add something like this I could never make it for a single DAW (Pro Tools Only) and would need to make it work for Nuendo/Cubase, REAPER and other DAW's also I support and that is massive amounts of work.

FYI: not sure if you saw this cool new dialog tool that already works with BaseHead
Absentia DX - Transcribe
https://www.youtube.com/watch?v=dwwY1KcBVfU

cya!

s>

Reply
1 Reply
Customer
Joined: 4 years ago

Posts: 46

I'll butt in here as a Basehead user who wears the dialogue editor hat most of the time and is also very familiar with pretty much all the current options for dialogue-related workflows.

Personally I think that it'd be misguided for Basehead to chase any EDL wrangling and other assembly features because it just has never been a product intended for that, and with the current options available out there, it'd be a tall order, too. Leave that to Kraken, EdiLoad, and MatchBox.

Searching dialogue bits via a transcription text search, however, is a natural extension to a product that is already designed to search audio via various metrics (very flexibly) and spot it into a DAW... I put in a feature request for this -- two or three years back, it's in the request base somewhere -- it didn't gain traction at the time. Absentia DX process with Basehead (which I actually brought to ToddAO's attention originally as that's the process I ended up using two years ago) relies on having to embed metadata into existing files, which is not only much more lengthy process but also something that isn't generally desirable and is nearly always best to avoid. IF it was possible to import marker/region info into Basehead from a spreadsheet (I don't THINK it is, is it?), then one could perhaps import the spreadsheet generated by Absentia transcription into Basehead, thus avoiding having to embed new metadata and keeping the original media fully intact. But it'd still be some overhead wrangling it. Imagine instead just hitting "transcribe" on a group or an import or a database in BH and having that data generated directly...

Absentia's own alts finder would be good IF it allowed any sort of filtering of the results so they could be narrowed down better. As it stands, it is only good for finding EXACT alts but not part-word cheats and the like, because you cannot narrow the search down to a single person/character in any way; neither by metadata (channel name) nor by a string in a pathname.

Kraken at this time indeed is THE most flexible solution for this, but for this alone, I personally don't believe it is worth the price of admission. And the moment any of the (well-known and few :)) major audio library apps add this feature, Kraken will DEFINITELY lose its sheen. It'll still have the matchback functionality (realtime sync to what's selected in the DAW, showing all alt takes) -- but that is not where the real time saving is and is very minor, IMO.

 

@Steve T I really hope at some point you folks can re-consider implementing this feature into BH. Perhaps only to rub it in to your main competitor, who does have it coming? If not for any other reason? 🙂

 

 

Reply
Posts: 566
Admin
Joined: 5 years ago

@makarushka Tall order is an understatement.  That is a Venti order!   hahaha  😉

I have planned CUE Marker searching in basehead 2024 and it's getting close to being added to the BETA for it now.
What is the problem with Absentia writing metadata into the file?  Are they not preserving existing metadata and blowing it out which is totally no bueno?  or is the time it takes?

The CUE chunk where traditional Markers are written is a separate chunk than iXML or BEXT where most the metadata is written.

 

lmk man!

Steve

Reply
1 Reply
Customer
Joined: 4 years ago

Posts: 46

Tall order is an understatement.  That is a Venti order!

 

I bet! 

 

What is the problem with Absentia writing metadata into the file?  Are they not preserving existing metadata and blowing it out which is totally no bueno?  or is the time it takes?

 

They do preserve metadata (have a setting for it actually) but the process changes the timestamp (obviously) and -- for less obvious reason -- file size. But even if it didn't -- it is wrong on principle/conceptually to modify the original production audio in any way. It is the only point of true reference left in the process. There are only rare extreme cases where original production roll media NEEDs to be modified in any way -- like fixing some catastrophic timecode errors, and even that now can generally be handled without it.

 

Funny enough, just today Absentia released an update to their Alts Finder which implements a filter by both the channel/character name AND a pathname search, so that's  significant functionality improvement. I have yet to test it out. If it works, they only need to add exact string matching (for now will only match multiple words in any order unless I am not aware of some hidden syntx options) and an option to ignore punctuation (or not)...

Reply
Posts: 566
Admin
Joined: 5 years ago

Yeah the Dialog workflow is all about referencing original files so I can see why that wasn't a smart move.  Maybe they could write a tiny file next to it called [filename].cue that copies the CUE Markers they write into that.   In one hour we could make basehead 2024 look for that file and read and write to it instead of CUE chunk in the original file as this data we read live already on each record click so easy on our end.   Try to convince them to do that and I will add support for it cuz it's a simple task.  😉

We would need to talk to settle on a format but I know those guys so easy peasy if they agree.

Reply
1 Reply
Customer
Joined: 4 years ago

Posts: 46

Yeah the Dialog workflow is all about referencing original files

 

Thank you 🙂 Indeed!

 

Maybe they could write a tiny file next to it called [filename].cue that copies the CUE Markers they write into that

 

But they do that already -- they write an .xls. That's the other option in Absentia that doesn't write to the files as mentioned in my first post above. Absentia can either generate a SINGLE .xls per each file transcribed -- which lives where the production file lives -- OR they generate a single "project" .xls per the whole transcription job. So the data is already there...

BTW, this is also the Kraken approach: they generate two hidden files per each production file scanned, in the same location: one for the log and one for the actual transcription text.

Personally I like individual .cue files approach less because of the doubling or tripling file descriptors in the file system. And again it's adding something to the original dataset that wasn't there before, and why do that when you can have a single database (in whatever format) elsewhere?

In one hour we could make basehead 2024 look for that file and read and write to it instead of CUE chunk in the original file

Well, how about implementing a cue region/ marker import feature (user-triggered) -- all the info is in that project.xls file already: file names, cue start and end timestamps, transcription text... This is what I was asking about in my first post -- cue/marker region import. And this way it wouldn't have to be Absentia-specific, either -- just follows a certain syntax like any other text import...

And this would only have to be read-only, too -- nothing needed to write? One-time import, no?

Still, if the transcription was built-in, it'd be so much nicer. I get it that it's a whole other proposition in terms of implementation effort and licensing costs for those third-party engines (have no idea what they cost) BUT it then also would instantly make Basehead a lot more attractive proposition as a standalone Dialogue editor's helper tool. Huge value compared to the competition -- in my opinion. Of course I myself have options and access to any and all of these but I also would GREATLY prefer not to have to go anywhere but BH for all such needs.

 

Reply
Posts: 566
Admin
Joined: 5 years ago

Please Attach one of their .xls files to look at also the Kraken ones.

s>
BTW: We already have a [field] in the basehead 2024 database for marker data so we can make it searchable.

Reply