I’ve been shuffling stuff around lately with my DVD collection, and one thing I’ve been doing is cleaning up my DVD ripper and web frontend to catalogue my entire collection (todo: put in git, trac). I finally finished archiving this weekend all the cartoons I have, and I actually finished ripping all of them that I want to archive, too. They’re not all in one place yet, but by the estimates I’m running (one nice feature of my new code) is that it’s gonna take about 750 gigs of storage. Whee! It’s all worth it to have 8 seasons of Super Friends on demand (seriously).
I found a few bugs in my ripper this weekend, one of them was that I was only storing one possible subtitle type in my Matroska rips. If a DVD had both VobSub and Closed Captioning, it’d only mux the first one I added. Fixing it was fun, since it was one of those moments where you open up the code trying to find the reason for it, and you find a big comment labeled “FIXME: Add this feature here.” Heh. So, now it muxes both, if available. Woots.
There is still one DVD subtitle format that I am having absolutely zero luck in finding anything about — English SDH (Subtitled for the Deaf and Hard of hearing). According to Wikipedia, it’s basically closed captioning with color. I can play / watch / rip closed captioning just fine (watching: mplayer -subcc dvd://, ripping: ccextractor), but not SDH. And I haven’t seen anything that can even play them yet, although in fairness I’ve only been playing with Linux applications. And everytime I try to explain to someone what I’m trying to do, they think I’m talking about VobSub subtitles. Usually I get tired of trying to explain the difference and give up searching. I could try finding some Windows apps to rip / play them, but if I can’t get something in Linux that’s scriptable to access them, then it doesn’t matter anyway. So, if someone knows of something … plz to drop me a line, kthx.
Speaking of subtitles and MPlayer, I’ve come to the conclusion that MPlayer’s support for them is just plain sub-par. The options to play them back (or force them off) are buggy and inconsistent across the bar. For example, here’s a small roundup:
– Flagging a subtitle track as “default” when muxing a Matroska stream means that, if you turn on subtitles in the viewer, that should be the first one to show up. It does not mean “these are forced subtitles, so display them automatically.” That’s why Matroska has a “forced” tag. default != forced. If you’re still lost, look at the original audio and video tracks, and you’ll see they are also muxed with the “default” flag fipped on. It’s purpose makes more sense with video with multiple audio tracks — if there’s more than one, which one do you play by default? The one with the “default” flag! Same principle should apply with subtitles when you turn them on.
– MPlayer can’t load Matroska subtitles externally. You can, if you wish, mux just subtitle streams into a Matroska wrapper (ex: mkvmerge subtitles.{idx,srt} -o subtitles.mks). But using “mplayer -sub subtitles.mks” won’t work. Bummer. 🙁 I understand that in this case, the Matroska stream could contain more than one subtitle stream (VobSubs and CC in my example), and it generally expects just one (-sub subtitles.idx, fex), but still, it’d be a fancy feature. 🙂
– MPlayer can’t dump CC to SRT, even though it can play them (mplayer -subcc). Bummer.
– Random rant about -noforcedsub and -nosub and -sub are conflicting / confusing, but too lazy to put together data about it, and it’s mostly related to the Matroska one above.
I just had to get that stuff off my chest. 🙂 I have faith in MPlayer eventually improving in said areas, and filing bugs would probably be good on my part. I generally don’t deal with subtitles much anyway, so for me it’s kind of a “would be nice to have” set of features. Meaning, I’ve already worked around the bugs and they don’t bother me as much anymore. I would be curious to get SDH read support though.
I’m starting to notice a general trend here — I complain a lot about certain issues and bugs in detail, but never go out of my way to report them. I’m becoming the kind of user that as a developer I totally hate! Oh noes!
In reality, I like being able to be on both sides of the coin, and I’d have to agree with the assessment of most user complaints I see, that are: the barrier to entry to reporting bugs is too hard. I could go into detail about that, but I don’t really want to, as I don’t wanna focus on the negative. But generally speaking, sometimes it’s too much of a hassle to easily report a bug. If it means me creating yet another user account on a bug tracker or subscribing to a mailing list, I weigh that against the strain of just ignoring or working around the bug.
I am, of course, to blame for my laziness, and I completely understand that developers (such as myself) need a detailed report with contact information along with the ability to quickly index reports. I wonder if there’s some magical middle ground, though, where users who aren’t regular bug reporters can just easily report their issues and be on their way. I know in Gentoo, we tend to use the forums as a poor-man’s bugzilla sometimes, and maybe that’s one way to do it. Interesting stuff to think about. Drive-by bug reporters, kinda thing. They’ll come by once or twice, but not regularly.
Anyway, I can’t think of any other interesting DVD stuff I ran into this weekend. Other than I bought season three of Taxi and it wasn’t as entertaining as I remembered it to be. Oh well. You win some, you lose some.
As I see it you as a user should not need to create a hell lot of bugaccounts, that should be something for the maintainer in the distribution to make.
And that is the really sad part of the “understaffedness” of Gentoo. We can talk about ebuilds all day long, but having to few maintainers to sometimes have a stable and reliable communication channel with upstream and can handle bug is really something that is a loss for gentoo.
What? That doesn’t really … have much to do with what I was writing about. 🙂
I was talking about upstream, but whatever.
Er, yah .. *confused*
“But generally speaking, sometimes it’s too much of a hassle to easily report a bug. If it means me creating yet another user account on a bug tracker or subscribing to a mailing list, I weigh that against the strain of just ignoring or working around the bug.”
This was what I commented about.
In a perfect world the user should only need a bug-account for their distribution, and the distribution/maintainer should have bug-accounts/mailinglist knowledge for upstream, but also the time to help the user get the problem fixed without pointing the user to upstream.
I know I am one of those too that think everything should be reported, but sometimes is just “too lazy” to find out where to report it, try sort out all info by myself that they may need and send it to the right place.