Handbrake can also rip dvds, if you give it the external libraries needed to decode them. The UI is great for finding the track with the actual movie and pulling in all the audio tracks and subtitles you want.
I have used this in the past, but I've never been able to get the subtitles to sync up properly. Typically they're copied over, but the first subtitle will start as soon as the video starts (as opposed to when the first spoken words start) and end when the video ends, with all the rest of the subtitles spaced out apparently according to the correct proportions, just at the wrong times.
I've tried fiddling around with when the subtitles should start, but because the subtitles end up stretched out so much, that makes all the later subtitles wrong. And I'm typically ripping a bunch of TV shows, so I want to do as little manual work as possible for each episode, because that all adds up quickly.
Do you know if I'm missing a library or a setting somewhere? Maybe I just need to try again with the latest version and see if it's been fixed over time.
HandBrake requires a patched version of libavcodec/libavformat libraries. Some Linux distributions like to link it to their system libavcodec/libavformat versions, and this breaks many things, DVD subtitles too.
However, if you are using a version that's linked with the right libraries, it's probably a bug that should be reported.
Subtitles are an issue because even if they're "correct" from source (as a synced track) they often have other issues, raw subtitles are still very much YMMV (Your Mileage May Vary).
If you care enough about subtitles and are converting for future reference then it's worth using SubtitleEdit to correct | align | correct case | spell check | generate translations | etc and then merge final (video + audio) tracks from HB with SubtitleTracks using (say) MKV Toolnix.
These are tools that can be streamlined and batched (with some degree of learning curve).
> so I want to do as little manual work as possible for each episode
I typically transcode Audio+Video, seperate out subtitles automatically along with "most common least destructive" touchups scripted and then watch.
You can achieve this by dropping input file in a watched folder and having the results plopped out in a "to be viewed" folder.
Most of the time everything is A-OK .. when the syncing is out I correct it via SubtitleEdit and continue watching.
You can save Episode.mkv and Episode.srt together, or batch bind the srt into the mkv as you store OR you can go to town with multiple subtitles if you're a media meta data nerd.
Check out Subtitle Speech Synchronizer [1]. This uses speech recognition to listen to the audio track, and make whatever corrections to the subtitles, outputting it as a .srt file. Works great.
Additionally, vobcopy (with those libraries you've mentioned) is a great CLI video dvd ripper to clone the top level directory tree to disk rather than immediately transcode. I've used it many times to save old family DVD video stuff. From disk I can transcode it into modern formats with tools like Handbrake or Avidemux, depending on the recipient's needs.
> I click on the file and "open with handbrake" and press "convert". I can't imagine how anything night be faster.
I use both. One thing I prefer about ffmpeg is that I prefer it when I'm being a control freak.
Basically, if I'm encoding a lot of videos, I will sometimes fail to notice that some box has been ticked in Handbrake, that will screw up my encode. In particular, Handbrake always defaults to resizing my videos, 100% of the time, and I always have to turn that off manually. If I fail to do that, it will resize my videos and I'll end up wasting an hour doing encodes, or 3-4 hours if I'm using CPU instead of GPU.
The handbrake GUI has a drop down list of encoding presets. I find that as an amateur, selecting one of those presets is the best way to make a file smaller.
Handbrake is supposed to make things simpler than ffmpeg, except that it does not.
> I find that as an amateur, selecting one of those presets is the best way to make a file smaller.
These presets are not helpful when you want to try to make something specific like "I want to make this file fit in 3GB" which is something that an amateur typically wants to achieve.
It's not even that hard to actually do, which makes me wonder why Handbrake has never implemented this kind of things.
Given how CD/DVD/BluRay went out of mainstream, I think the more typical use case is "I want the file smaller, while retaiming FullHD, HD, SD quality" for archival / streaming, for which the profiles are fine.
> "I want the file smaller, while retaiming [sic] FullHD, HD, SD quality"
The problem is that "retaining X quality" is extremely vague and subjective. Also, a lot of people conflate resolution with quality (see YIFY Torrents). While yes, you need enough pixels to have reasonable quality, if the encoder set CRF to 50, 8K video won't save you.
Handbrake gives you no indication whatsoever what quality you are getting at the end of the day. Even though it's technically possible to do many things in that regard (make previous of different compression rates and let the user decide, or draw comparison of video clips before and after compression highlighting where the image details are lost, etc...).
There's very little that is user-friendly in Handbrake.
I agree with ekianjo, it would be great if Handbrake had a 'fit to 700MB' option.
After trial and error, I found the original file size to be preserved and not to correspond to the presumed smaller output of say a lower resolution output.
You can do this with a two-pass encode and a calculator. Take your desired filesize and divide by the runtime of the video. Put that bitrate into the UI. (It does seem they could add this to the program.)
It would also work with a one-pass encode, but setting the bitrate that way risks wasting space in simple parts of the video and degrading quality in complex parts. Two-pass encoding takes longer but distributes bandwidth better.
I haven’t used in a while, but handbrake did have really useful presets for a variety of devices: it was useful because there are a lot of video compression knobs to turn (you can still do so after selecting the preset)
I don’t know anything about them, ChatGPT figures it all out for me. I just say if it needs to lower quality or resolution, keep original, remove audio, keep subtitles etc
So you end up learning even less from that process than by using a CLI.
As long as you have this behavior for non-critical code it's just a little sad because you are delegating something you could easily have learnt. For hype sake I guess.
But if you do use this technique in a work related context you are just going to produce average code that you won't be able to debug when something break...
Not defending intellectual incuriosity here, but in fairness ffmpeg is the antithesis of "easy to learn." I capture Laserdiscs (i.e. sampling the laser's RF output and decoding in software [0]) for fun, and use ffmpeg as part of that chain – I still barely scratch the surface of what it can do.
No, I’m using an ADC modified for use with LD captures [0]. I did this because it’s cheaper in theory, although with the amount of time I’ve dumped into getting it working and keeping it working, the $500 or so for the Domesday Duplicator may well have been a better choice.
> you are delegating something you could easily have learnt
This is the only case I would ever use a text generator. If you cannot understand it, you cannot trust the output and you cannot learn it in case of doubt.
This is why it is so great for grammar and protocol, but very problematic for actual research questions.
You don't have to take the first output you get. It's as if you can play with it before you make it production. No one is suggesting putting "make the thing in a way" in a pipeline. Stop fighting strawmen.
But chatgpt has no knowledge of the format of your file. Unless you provide the output of an ffprobe as part of your prompt. Like if the source is a dvd, there are all sort of ratio issues, deinterlacing, how you deal with subtitles, etc.
Feed ChatGPT's output to a question, back as input to it, say it was from a human (1, amateur, 2, expert) and for each case, for that question, ask it if it is correct.
ChatGPT is like gambling, even though with slightly better odds. It can suggest complete nonsense with seemingly great confidence.
If you have true experience in some field try to ask ChatGPT some questions and you will be shocked what nonsense it suggests, put in very nice words.
From a random blog post that a search machine brings up you can often get some clues whether the author has good understanding or just wrote down a random finding they had during trial and error. And that finding is still more on the side of error than doing it correctly.
You can further gauge the accuracy of a blog post if the author included links to sources. ChatGPT doesn't bother with sources because it can't trace any statement it makes to a source.