Hi, Am Montag, 9. Juli 2007 22:06 schrieb Michael Riepe: > >>Does that work with multi-file sources already? > > > > Yes, of course... > > That's what you thought ;-) No, I tested it... ok, just one time and only with 12 rather short TS's supplied in a project file.
Also I can't see why it should not work, because I just do the same as with marker pairs comming from the project file. > > I also had to change the -batch option because it didn't accept multiple > filenames. Your patch just went in, by the way. > OK, that's right... -batch (as it was) only accepted one file... > >>>for instance to give the path to the index file or to supply multiple > >>>filenames or to specify the location of the export file (a patch Sven > >>>hopefully will commit soon... would be nice if he also could add a > >>>-expfile CLI switch... ;-)) > >> > >>Shouldn't be a problem to add that option. No need to bother Sven. > > > > Sven told me yesterday that he needed that option and implemented it > > already, i.e. to specify <expfile=...> in the project file... > > What is it good for, except causing trouble? :-( > AFAIK, he produces automatically project files with cuts (by scanning a video with a special ffmpeg vhook modul) and dvbcut writes (after short manual refinement of cuts) to a fixed temprary file name which is used/expected by some other tool. > I already have trouble enough with the absolute paths in *.dvbcut. You > can't even move a project (both source and *.dvbcut files) into another > directory because dvbcut will just say no, err, "file not found". Nor > can I use files on a NAS or other external storage device, set the > markers from one host and run the export on another one, unless the NAS > is mounted at the same directory on both machines (which is not always > possible). Yeah, that's the problem with absolute path... but I'm sure with relative ones there are some other cases where it not works... > > Besides that, the typical workflow is like this: > > - load and index source file(s) > - set markers > - save project > - export Typical, but not the only possible... see above... > > Often I process a number of movies in sequence, without exporting them > at all - because it's much more convenient to run the export in batch > mode afterwards (while you're already doing something else). Therefore, > when you save the project file, the name of the export file may not yet > be known. So what's supposed to be written to the project file? > Nothing... in that case the default name will/should be used like it is now! > > I just thougt that a > > CLI switch would also be nice, because at the moment one has to call > > "dvbcut -batch" from the position where one wants to have the output > > file. > > A CLI switch would not only be nice, it's the way to go. For batch mode, > that is. If you don't need the project file for a list of cuts, yes... but if you need a project file I would specify everything in it. > > >>But I don't think that specifying the export file name inside the > >>project file is a good idea. > > > > Why not, it's the best way when you want to generate a project file by > > some automatism for batch cutting! > > Until the program overwrites a file for the first time because its name > was hardwired in the project file. No surprises, please. In Svens application that's exactly what he wanted... ;-) ciao Ralph ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
