Forum Replies Created

Page 22 of 43
  • Robb Harriss

    November 9, 2011 at 3:20 pm in reply to: clips via xml

    Thanks Bryson.
    single sub clips drag and drop into FCP just fine, defined at their marked limits. Right now I’m just using a CMX EDL and capturing the clips from scratch, and that’s working fine. But I’d much rather no go through the effort and simply use the CatDV clips, especially since a lot of them are already in ProRes Proxy. All I’m doing is repeating my work.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    May 3, 2011 at 9:35 pm in reply to: Re-rendering proxies

    Got that. And I think the path-based is the way to go. It just goes to the origins of where you started. I mean DV is in the name. Is anyone over there still shooting DV and using a product as sophisticated as this? But you’re stuck with certain thing. Of course version 9 could be “Super Deluxe Best Ever Logging and Asset Management system.” Or you could do the Apple thing and just skip to version X

    I’ve been fixing the paths. Update Media Location is working like a charm. I’m removing the old conflicting Raid Set-1 references. I think I have all the previews popping up correctly, at least reading the files from one location. I have to try the laptop.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    May 3, 2011 at 3:57 pm in reply to: Re-rendering proxies

    [Rolf Howarth] “The reel name isn’t added by CatDV, it just uses whatever the original file name was.”

    Yes, that’s actually making my point. The same doesn’t happen when using tape-based. Look at it from the viewpoint of someone who doesn’t live and breathe this every day: Tape-based doesn’t have the tape name, but path-based does have the tape name. There exists a point of confusing when using the word “tape.”

    I’d already written a database for all this, but CatDV is infinitely better. I mean there’s not the tiniest bit of comparison. And now we live and breathe CatDV. It’s really more important to the operation than any of the editing software. Logging is the root of all editing, as far as I’m concerned—even more so for Non-Linear Editing. The logs are the true non-linear access to the footage.

    The following screen grabs just try to illustrate my point of confusion over the terminology. I’m going back and fixing the paths using the “original” location for the full-rez footage. I already changed the drive names and I’m reattaching the media to switch the drive path in the database. I’ve moved the previews into directories whose paths match the original footage. It seems to be working, but every once in a while one of the previews just doesn’t want to “stick.” By that I mean I can get it to work initially, but when I come back later it’s no longer found.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    May 3, 2011 at 1:13 pm in reply to: Re-rendering proxies

    what I mean is that the path-based files have the original reel name as part of the file name, while the tape-based previews have what looks like a hash code as the file name. I can look at the path-based files and see what it is and where it came from. Can’t do that using the tape-based previews, not unless you open the file and it has the reel name burned it. I’m thinking that the term for tape-based should be changed to something less inviting like “old format,” if you catch my drift. For someone coming, as I do, from decades of a world filled with 8.3 reel names and timecode, the term “tape-based” is actually very attractive. Maybe that’s not so with the later generation, many of whom don’t even know what a tape deck looks like. And yes, I have exported CMX EDLs from CatDV. Actually, they were GVG because I prefer the audio format.
    I got lost on “original” because I couldn’t tell if meant the original full-rez media, or the path where the previews had been originally stored. I was thinking the latter, because the full-rez had never moved but the previews had.
    Thanks for the help. I’m running a couple more tests to see if I can fix the issue. Then I’ll switch everything over to path-based.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    May 3, 2011 at 12:36 pm in reply to: Re-rendering proxies

    Geeze, I hit Post Direct before fixing my typos. Oh well.
    Thanks for the help, it’s been huge.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    May 3, 2011 at 12:35 pm in reply to: Re-rendering proxies

    Bryson and Rolf,
    Thanks for getting back. I know what you mean about going through the posts. I do a lot of support on the Apple support sites, myself. And just so you know, I’ve earned my gray hair. Designed and built a number of facilities and go all the way back to B&W reel-to-reel 1/2 tape. And been through laser disk, and then montage and then doing digital non-linear when Avid was still a dream in Tewksbury. I believe that CatDV isn’t all that difficult to setup and use, and I’m a big fan. But there’s some weakness in terminology, direction and intent (yes, I write tech manuals, too). We’ve been making great use of CatDV for several years now. I can easily say that it’s the single best addition to the facility in years. And it’s relatively easy to get a non computer-oriented writer or producer up to speed and doing useful work.
    Up until now the drive naming conventions haven’t hurt us. That’s because each of four systems is sandboxed. When we move a project the path appear the same to the editing systems because we’re not mounting network volumes for editing. And acutually we haven’t had this current propbem with CatDV until just now. The eported XML always contained all the media. So something’s weird. But I did manage to fix that.
    So now I’ve gone in and renamed one drive. That should sort out that part of the issue. We only ever had one path for previews. But I’m going to look at Rolf’s suggestion to have a separate directory for tape- and path-based previews. I’m re-rendering some of the previews, and using the new paths for all. So we’ll see.
    As I look at it the path-based files look more like tape-based files, at least at face value. After all the path-based utilize the actual reel names, as well as the paths. That’s very cool, as far as I’m concerned. And because they’re in a playable format with the reel name and timecode burned in I can hand them to someone as it if they want to look and make some loose notes.
    The definiition of “original” could be a little more precise. Suggested workflows could also be a little stronger. Point of fact we really haven’t had a single problem when running the system off the laptop and using the previews on an external pocket drive. Works like a charm. The description of the “archives” lulled me into interest, but I’m heeding Rolf’s warning. There really should be some caviate in the documentation. Ok, get this. I made the 8.1 documentation into both Kindle and ePub ebooks so I could read them on my Kindle and iPad. Nothing like curling up on a chilly Spring evening with a good manual. And no, I have no life ;-). I’ll let you guys know what happens as a result of the renaming and moving.
    Robb

    Non-linear: all the time and nothing but.

  • Robb Harriss

    April 30, 2011 at 4:48 pm in reply to: Re-rendering proxies

    So I switched to path-based, or rather added it. I used the preview manager to delete the proxies in one of my catalogs. Now viewing of previews has become very spotty to non-existant. Fortunately I started with plenty of hair or I’d be bald now.

    I learned a couple of things that have been sneaking up on me over time.
    When I setup our different FCP systems I knew that projects would move back and forth from one machine to the other. I thought I’d be clever and name the raids and external drives the same. I never anticipated sharing the full rez footage between machines because they’re only using internal raids and they’re just on the internal gigabit network. On the other hand I knew that the external firewire raids would go back and forth between the MacPros, and laptops and even home. I thought by naming those the same that FC would always know to find the footage. It ain’t so. FCP is using the drive ID at a lower level, so it knows the drives are different. Ok, one issue.

    The next issue I only recently while messing with CatDV and refining our catalogs. Get this: Sometimes I am accessing the full rez footage from across the network—not to edit, but to import footage into CatDV and/or to make previews. I’ll use one system or the other to pull HDCAM footage into FCP and then import those clips into CatDV. But the raids have the same name (Raid Set) on both large systems. Here’s the rub (and I know some of you see this coming). When I’m local on a machine the raid is “Raid Set.” If I pull from the other system’s raid the path is /Volumes/FCP Edit2/Raid Set-1. But when I move into the other room and work from there, the relationship and paths filp, so the old Raid Set-1 is Raid Set and the old Raid Set-1 is now Raid Set. This even though the footage is coming from the same directory on the same machine. No wonder I have all these extra paths and Raid Sets and Raid Set-1s, now with footage duplicated in them. Yeah, so I’ve renamed the raid on my #2 system. I haven’t been using it much and there isn’t much on it.

    Setting the previews to path-based hasn’t seemed to be an improvement. Half the time the systems still can’t see the preview. Note that all the previews are, and have been, in the same location: a shared drive on yet another machine on the network. I’ve been using tape-based for ages (year or two?) without much of a problem. My workflow has been for a writer to create a sequence in CatDV using previews. I take that preview into FCP and it pulls up the timeline populated with the previews. We refine the cut, and when I get close I conform by reloading the footage from camera originals at full rez. It’s been a great system. But recently some of the timelines in FCP were not fully populated. While most of the shots were visible from the proxies, some showed as offline, even though the preview version existed and worked in CatDV. Hmmm. I did some wrangling and filled in the missing bits, but it was very tedious. I was hoping that path-based would solve this new issue. But now the previews keep getting lost. Unlike the full rez footage there’s no way to relink the previews, and they haven’t changed where they live, and the path is still in the field in the preferences.

    What’s confusing me is how to add the paths to the preferences for path-based previews. Tape based were never a problem. Now I’m not sure what the word “original” means. Is it the original full-rez footage? Or the original path where the previews were created and stored, which hasn’t changed. Do I need to put in a “new” path for each clip, each directory, each tape? The tape-based make previews function stored clips from each tape in a separate folder in my CatDV Previews folder. The process using path-based has created the new Volumes folder in my CatDV Previews folder. Within Volumes are folder structures that mimic the paths to the full-rez footage. Hence my question about “original,” Does it mean preview or full-rez path? Argh.

    And path-based doesn’t work with catalog archives? Wouldn’t an archive be the way to go for a catalog on a portable drive that I take to work on at home using the laptop?

    yes, I stepped off the deep end with this. I went from a system that was 99% working and messed it up myself.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    April 30, 2011 at 4:18 pm in reply to: previewing proxies

    I’m having a similar issue after having now setup path-based previews. I’ll explain my hair pulling in my post below.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    April 28, 2011 at 3:44 pm in reply to: Re-rendering proxies

    Bryson,
    You’re hitting that proverbial target spot with that accepted means of basic construction.

    What looks normal for me may not work so hot for the machine. It’s the one adding the extra data. I am not about to change it without checking. It’s still odd because the path-based structure to me looks more like tape-based, where the bins and original clip names show up. I live and breathe by reel name and timecode (for a generation and a half now). If you saw my preferences screen shot does that look good to you? I know I’ll have to add the portable drive to the path when I go to use the laptop. But can I just copy the previews with the existing structure? Or do I now need to make an archive? And yes, I understand that CatDV will search the listed paths starting at the top. I figured out that I needed to use the Preview Manager to delete the old previews, so now I’m rerunning them (low rez photo-jpeg) from the ProRes files that are the original media.

    Non-linear: all the time and nothing but.

  • Robb Harriss

    April 28, 2011 at 2:32 pm in reply to: Re-rendering proxies

    Actually I wrote the same path where everything else, the previews that is, are stored. CatDV made this elongated path. I don’t mind it but it seems to be excessively long. I also don’t mind seeing the original bins. As you can see in the screen grabs below, when using tape-based the reel names became the folders. I would have thought that the bin names would have shown up in this list. Instead I got the Volumes folder with the longer path in it. I am getting a little concerned with the RAID Set, RAID Set-1 folders because these are in fact the same. Normally I get RAID Set for machine #1 on the network and RAID Set-1 for the raid on the #2 machine. I’m using the footage on machine #2 to figure this out. I’m thinking I’ll have an issue when I go to add footage from the raid on machine #1. Will I get RAID Set-2 to describe what I would have thought was RAID Set. I’m trying to prevent a problem as I move into this new workflow. And I’m still not sure how this will work when I use the laptop and make changes to the catalog.
    Thanks

    Non-linear: all the time and nothing but.

Page 22 of 43

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy