Digitizing my old tapes was one of the most rewarding side projects that I did over the last year. I managed to get in under the wire (pun intended) of Firewire compatibility on Sequoia and a long daisy-chain of adapters. But it was clear the days of this approach were numbered. I'm optimistic these 3rd party accessories will become more standardized into self-contained cheap boxes where people can easily transfer over their stuff before camcorders degrade.
My pipeline went camera -> dvrescue -> ffmpeg -> clip chunking -> gemini for auto tagging of family members and locations where things were shot.
We now have all our family's footage hosted on a NAS with Jellyfin serving over Tailscale to my parents Macbooks. I found the clip chunking in particular made the footage a lot more watchable than just importing the two-hour long tapes although ymmv.
I am going to finish such a project soon myself, including some old Video8 tapes! Sounds like you're on macOS, Any reason you didn't use iMovie for the capture itself?
The Video8 tapes have already been digitalized via a Digital8 camcorder, but apparently you can get even better quality out of old analog tapes with the vhsdecode project. Let's see if I ever get around to that, but at least it bypass Firewire entirely:
https://github.com/oyvindln/vhs-decodehttps://www.reddit.com/r/vhsdecode/
Mostly wanted to fully automate the pipeline (auto-rewind tape, scan tape head position, etc) and iMovie is just using the same AVFoundation APIs under the scene that you can call manually. Took some notes here if helpful:
https://pierce.dev/notes/automating-our-home-video-imports
Wish vhsdecode was easier to use in practice! Such a cool idea but a bit too inconvenient to hack your own hardware like this...
I used dvgrab to ingest my old tapes, and ffmpeg and avisynth/QTGMC to de-interface and encode files for easy viewing (though I keep the original .dv files).
The biggest issue I ran into was that while the audio and video were properly synced up in the original .dv file (due to it being an interleaved format), when I re-encoded the videos, the audio and video would drift out of sync as the video went on.
I was able to fix the sync issues by using dvgrab to split the original dv file into a bunch of 3 minute chunks. I then wrote a script to extract the audio track from each chunk, pad the end of the audio with milliseconds of silence to the exact length of the video track, combine the padded audio tracks, encodes the combined track, and muxes the fixed audio track with the encoded video. This worked really well; the silence padding is imperceptible, but the audio and video are still in sync - even after 2 hours.
A final point that needs making is that doing anything with dv files in ffmpeg (even -c:v copy) destroys the SMPTE timecodes embedded in the original file, making it much harder to split by scene.
Just because I've dealt with this exact issue in the past, it may have been a 30fps vs 29.97fps issue. For me the audio was a fixed length, but the frame rate was SLIGHTLY too fast. The problem can manifest as either too slow or too fast depending on which side is expecting 30fps vs 29.97fps.
I think it was just clock drift on the camcorder during the initial recording, as I'm pretty sure I tried adjusting the frequency of the audio track to make it the same duration as the video track, and the A/V sync was still wrong.
I'm so glad the audio and video tracks are stored interleaved, as it made my solution possible, and the results I got were great. By splitting the interleaved video into small enough chunks, padding the audio, and cutting it exactly to video length, the padding was practically imperceptible.
The only issue I ran into was that ffmpeg can't cut audio with any real precision. I eventually figured out that I could dump the audio track to a headerless PCM file, calculate the exact byte offsets for my cut points, and cut them with perfect precision using the head and tail commands from GNU coreutils. This was perfect because I was able to use the cat command to combine all of the padded audio chunks into a single raw PCM file, which I then made an AAC encode of with ffmpeg to mux with my original encoded video track.
Ffmpeg's dvvideo implantation is unfortunately just broken and mangles timecodes, even if just doing a stream copy from dvvideo to dvvideo without any re-encoding.
Fortunately, dvgrab does allow you to take the original .dv file and generate a .srt subtitle track with time stamps that you can mux into your encoded files.
If you are capturing I find dvgrab is pretty good. It's what I've been using for about 25 years now!
In the olden days when I got paid to shoot real video on a VX2000 and edit it for people, captured using a PCI Firewire card and dvgrab in Slackware, rewrapped with probably mencoder shading towards ffmpeg when it became more popular (and developed!), dual-boot into Windows 2000 and cut in Premiere 5.0, then back into Linux to transcode back to DV if I wanted to write it out to DV tape.
These days I shoot on a PD150 or DSR500 (and quite often some HDV cameras), capture via a PCIe Firewire card and dvgrab in Ubuntu, rewrap with ffmpeg, and edit in Resolve, without the dual-booting step.
If you use dvgrab it will split the capture up into separate clips on shot boundaries based on the pause/unpause markers on the tape. I have not found a way to extract good/no good from the stream, but if you're not shooting on a broadcast camera you don't have this anyway. Timecode is preserved though!
When you load it all up in Resolve, one of the options in the Cut page is "Source Tape View" which runs all your clips together by timecode, and lets you view them as though they were a continuous tape of your rushes, which is how we used to do basic assemble editing in the olden days of clunky tape decks and edit controllers with big rows of red 7-segment displays.
Edit your old home videos. You can do that now, and they'll be far more watchable.
Went through a very similar journey recently as well. In my case using a Macbook was a non-starter, as certain adapters are prohibitively expensive these days, if you can even get your hands on one. Thankfully my son has a desktop Windows PC and Firewire PCI cards are cheap and plentiful, so getting connected that way worked out. Much better than an earlier attempt via RCA cables (simple but digital -> analog -> digital is not the way to go).
My pipeline was camera -> WinDV -> DVdate (to extract exact datetimes into srt subtitles) -> Handbrake (to convert to mp4).
> Digitizing my old tapes was one of the most rewarding side projects
I also wanted to do that, but then I realised I needed to invest more
time and may need some hardware, so one day I simply had enough, went
to a commercial shop and had them turn all the old stuff into digital.
The cost wasn't that huge either, so considering that I could also save
time (doing it myself), I am ok with that investment. Hopefully the future
has digital everywhere. Storage to be cheaper too, ideally.
As far as I've seen, local OSS video understanding models just really aren't there yet. I briefly looked at facial recognition models but a good amount of signal was actually in the video's audio instead of the raw video frames. Depends on the accuracy you're looking for at the end of the day.
Any idea how long the tapes will last? I have a bunch sitting in a box that I should probably verify have all been imported already before they turn to dust.
It would be fun to use this to build something like the old capdiv firewire hdd recorder I have. then you can just capture direct to disk and not worry about the 1:1 transfer time later.
Digitizing my old tapes was one of the most rewarding side projects that I did over the last year. I managed to get in under the wire (pun intended) of Firewire compatibility on Sequoia and a long daisy-chain of adapters. But it was clear the days of this approach were numbered. I'm optimistic these 3rd party accessories will become more standardized into self-contained cheap boxes where people can easily transfer over their stuff before camcorders degrade.
My pipeline went camera -> dvrescue -> ffmpeg -> clip chunking -> gemini for auto tagging of family members and locations where things were shot.
We now have all our family's footage hosted on a NAS with Jellyfin serving over Tailscale to my parents Macbooks. I found the clip chunking in particular made the footage a lot more watchable than just importing the two-hour long tapes although ymmv.
I am going to finish such a project soon myself, including some old Video8 tapes! Sounds like you're on macOS, Any reason you didn't use iMovie for the capture itself?
The Video8 tapes have already been digitalized via a Digital8 camcorder, but apparently you can get even better quality out of old analog tapes with the vhsdecode project. Let's see if I ever get around to that, but at least it bypass Firewire entirely: https://github.com/oyvindln/vhs-decode https://www.reddit.com/r/vhsdecode/
Mostly wanted to fully automate the pipeline (auto-rewind tape, scan tape head position, etc) and iMovie is just using the same AVFoundation APIs under the scene that you can call manually. Took some notes here if helpful: https://pierce.dev/notes/automating-our-home-video-imports
Wish vhsdecode was easier to use in practice! Such a cool idea but a bit too inconvenient to hack your own hardware like this...
I used dvgrab to ingest my old tapes, and ffmpeg and avisynth/QTGMC to de-interface and encode files for easy viewing (though I keep the original .dv files).
The biggest issue I ran into was that while the audio and video were properly synced up in the original .dv file (due to it being an interleaved format), when I re-encoded the videos, the audio and video would drift out of sync as the video went on.
I was able to fix the sync issues by using dvgrab to split the original dv file into a bunch of 3 minute chunks. I then wrote a script to extract the audio track from each chunk, pad the end of the audio with milliseconds of silence to the exact length of the video track, combine the padded audio tracks, encodes the combined track, and muxes the fixed audio track with the encoded video. This worked really well; the silence padding is imperceptible, but the audio and video are still in sync - even after 2 hours.
A final point that needs making is that doing anything with dv files in ffmpeg (even -c:v copy) destroys the SMPTE timecodes embedded in the original file, making it much harder to split by scene.
Just because I've dealt with this exact issue in the past, it may have been a 30fps vs 29.97fps issue. For me the audio was a fixed length, but the frame rate was SLIGHTLY too fast. The problem can manifest as either too slow or too fast depending on which side is expecting 30fps vs 29.97fps.
I think it was just clock drift on the camcorder during the initial recording, as I'm pretty sure I tried adjusting the frequency of the audio track to make it the same duration as the video track, and the A/V sync was still wrong.
I'm so glad the audio and video tracks are stored interleaved, as it made my solution possible, and the results I got were great. By splitting the interleaved video into small enough chunks, padding the audio, and cutting it exactly to video length, the padding was practically imperceptible.
The only issue I ran into was that ffmpeg can't cut audio with any real precision. I eventually figured out that I could dump the audio track to a headerless PCM file, calculate the exact byte offsets for my cut points, and cut them with perfect precision using the head and tail commands from GNU coreutils. This was perfect because I was able to use the cat command to combine all of the padded audio chunks into a single raw PCM file, which I then made an AAC encode of with ffmpeg to mux with my original encoded video track.
This is very likely it
Transcode to another format first that keeps the timecode?
Ffmpeg's dvvideo implantation is unfortunately just broken and mangles timecodes, even if just doing a stream copy from dvvideo to dvvideo without any re-encoding.
Fortunately, dvgrab does allow you to take the original .dv file and generate a .srt subtitle track with time stamps that you can mux into your encoded files.
If you are capturing I find dvgrab is pretty good. It's what I've been using for about 25 years now!
In the olden days when I got paid to shoot real video on a VX2000 and edit it for people, captured using a PCI Firewire card and dvgrab in Slackware, rewrapped with probably mencoder shading towards ffmpeg when it became more popular (and developed!), dual-boot into Windows 2000 and cut in Premiere 5.0, then back into Linux to transcode back to DV if I wanted to write it out to DV tape.
These days I shoot on a PD150 or DSR500 (and quite often some HDV cameras), capture via a PCIe Firewire card and dvgrab in Ubuntu, rewrap with ffmpeg, and edit in Resolve, without the dual-booting step.
If you use dvgrab it will split the capture up into separate clips on shot boundaries based on the pause/unpause markers on the tape. I have not found a way to extract good/no good from the stream, but if you're not shooting on a broadcast camera you don't have this anyway. Timecode is preserved though!
When you load it all up in Resolve, one of the options in the Cut page is "Source Tape View" which runs all your clips together by timecode, and lets you view them as though they were a continuous tape of your rushes, which is how we used to do basic assemble editing in the olden days of clunky tape decks and edit controllers with big rows of red 7-segment displays.
Edit your old home videos. You can do that now, and they'll be far more watchable.
A few years ago I did a bit more of a crude flow.
Play the footage on a tv in a dark room. Place a 4k camera on a tripod and record the tv with audio into the camera audio port.
Worked perfectly.
Actually not a terrible way to go from interlaced to progressive footage. Depending on the TV and camera
> gemini for auto tagging of family members
With all respect, reading this part made me feel uneasy.
Went through a very similar journey recently as well. In my case using a Macbook was a non-starter, as certain adapters are prohibitively expensive these days, if you can even get your hands on one. Thankfully my son has a desktop Windows PC and Firewire PCI cards are cheap and plentiful, so getting connected that way worked out. Much better than an earlier attempt via RCA cables (simple but digital -> analog -> digital is not the way to go).
My pipeline was camera -> WinDV -> DVdate (to extract exact datetimes into srt subtitles) -> Handbrake (to convert to mp4).
> Digitizing my old tapes was one of the most rewarding side projects
I also wanted to do that, but then I realised I needed to invest more time and may need some hardware, so one day I simply had enough, went to a commercial shop and had them turn all the old stuff into digital. The cost wasn't that huge either, so considering that I could also save time (doing it myself), I am ok with that investment. Hopefully the future has digital everywhere. Storage to be cheaper too, ideally.
Can you expand on the Gemini tagging part? What did you do with the tags, import them into Jellyfin after cutting the videos into parts?
Is it possible to accomplish tagging with local AI instead of Gemini?
As far as I've seen, local OSS video understanding models just really aren't there yet. I briefly looked at facial recognition models but a good amount of signal was actually in the video's audio instead of the raw video frames. Depends on the accuracy you're looking for at the end of the day.
Thanks for the reply. Let's hope local models catch up.
Discussion of prior post (FireWire on a Raspberry Pi): https://news.ycombinator.com/item?id=47535249
Any idea how long the tapes will last? I have a bunch sitting in a box that I should probably verify have all been imported already before they turn to dust.
My experience so far is that the tapes themselves are fine - but the required hardware/technology stack to extricate them is the real question mark.
Probably longer than whatever you capture them to!
It would be fun to use this to build something like the old capdiv firewire hdd recorder I have. then you can just capture direct to disk and not worry about the 1:1 transfer time later.
Oooh! Relevant to my interests :-)
I'll have a shot of this I think.
There are 5-12$ firewire to usb adapter cables you can get. no need to use a pi or hat. save money and use any computer.
Unless there has been some change recently those have never had the bandwidth or software support needed to capture DV.
You mean the ones on amazon that are just random ends on a cable? Yeah, don't plug that in to your computer or camera.
This would have been much nicer than suffering my dad’s 12 year old iMac I found in the loft.
[dead]