Matthias Schniedermeyer wrote: > Olaf Titz wrote: > >>> For playbackability with VDR in the 'simplest' case you only need to fix >>> the file-number in the index.vdr-file and append that onto the first >>> recording and move the XXX.VDR-files with the fixed name into the first >>> recording dir. >>> >>> But that way the overlapp would still be there. >>> >>> So you needed a program that finds the exact frame where the first >>> recording stopped. Then finds the exact same frame in the next recording >>> and then copies the portion of 001.vdr from the next-recording and >>> appends >>> and fixes the content of the index.vdr beginning after the frame you >> >> >> >> A bit simpler: >> >> 1. Move all the nnn.vdr files into new directories, renumbering them in >> the right order and make sure that each possible overlap is >> actually in one dir. E.g. if you have 1/001-1/005, 2/001-2/255, >> 3/001-3/023 you could reorder this as >> x1/001-x1/004 (from 1/001-1/004) >> x2/001-x2/099 (from 1/005, 2/001-2/098) >> x3/001-x3/178 (from 2/100-2/255, 3/001-3/023) >> (You can completely disregard index and other files.) >> >> 2. Run genindex in each of the new dirs. >> >> 3. Fix the cut-points. This is left as the only programming exercise, >> but supposedly noad can do this already (-o flag). >> >> 4. Run vdrsync --cut or whatever. >> >> I'm doing this routinely (by hand, don't ask me for a script :-) to >> join multi-part episodes of certain shows. Here the first step is >> trivial as most recordings consist only of 2 or 3 nnn.vdr files and >> for the third step I need noad anyway. > > > I like my idea better. :-) > > But i already have scripts for parsing index.vdr and finding a specific > frame in a recording. > (But i need it to find the same cutting-marks in the same recording from > a different VDR-instance(*) for find a the 'longest' (byte-wise) > recording which is most like without recording errors.) > > So all i needed to do if i had this problem would be a bit of glue for > the pieces i already have. :-) A little revision to my idea makes this very much easier and lightning FAST. Instead of finding the last frame of the previous recording in the next recording it would be better to find the first frame of the NEXT recording in the previous one. That way you only have to truncate(which is way cheaper than having to copy data) the end of the older recording part and move over the XXX.VDR file and paste the content of index.vdr with only needing to fix the file-number. No need to mess with offsets. That's it. 2 recordings merged into one. All in all this way it only takes a few seconds to merge 2 recordings. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
