Something occurred to me - you say “series” so I’m assuming this is a TV show, right?
TV shows can be the hardest things to convert, due to a whole lot of things. Frame rates can be tricky (the infamous ST-TNG is a case in point. These discs are among the hardest of any DVD to convert because they contain a bewildering variety of frame rates within the SAME EPISODE). For sure you want to use the very latest Handbrake to handle some of these things, but you may also need to get on the Handbrake forum and post some of your logs to see if they can help you with a proper encode.
You got it, Mike, it’s a TV show. I downloaded the latest nightly and I’m performing the conversion now as I type.
TonyPh12345 wrote:
I discovered that HB was incorrectly marking the framerate of CERTAIN episodes to 29.97 fps, whereas they’re ALL supposed to be 23.97.
Here’s something interesting, Tony: I looked at the mediainfo for the problematic files and noticed the frame rate being 29.97 fps. It’s interesting since all the other files that converted properly have a frame rate of 23.97. Now, under further investigation, I also noticed that the problematic files have the opening credits right at the beginning of the show, while the good files have them about 3 minutes into an episode. This makes sense now after reading your comment about ST-TNG series. Does this mean that all TV show credits are rendered at 29.97 fps? I don’t know.
Also, once I ran the problematic files through mkvmerge the frame rates were corrected to 23.97. Interesting, to say the least.
I converted the last 2 discs of the series with Handbrake’s “Nightly” version. I checked all of the episodes, and every episode worked great for the Live except for 1 episode. I’m not sure what happened there because the credits actually were well into the show before showing up! Nonetheless, I corrected the errors with MKVMerge and I’m now on my way.
The only drawback is the subs have to be separate from the files, but, I can live with that. As long as each and every episode works correctly. Anyway, I’m marking this thread as solved because it answered my question as to why some of the episodes had the video racing while the audio stayed the same.
I’m guessing he’s talking about the propensity for the WDTV to render Subs inside an MKV container without a black outline, and in some cases, they’re transparent. I’ve not come across the issue of transparency, but the lack of a black outline renders them unreadable if the background color is similar.
I think there’s an issue with the color palette getting lost by the WDTV. The primary color is USUALLY the same, but the border color is gone.
Yes. For some of the episodes, not all, the subs are rendered as black outlines if the subs are embedded within the mkv. This is strange since, like I said, not all the episodes are like this, only some. I used MKVExtract to rip the subs as idx/sub files, and then rename them to the same name as the mkv. Once they are external, the Live recognizes the files as subs and displays them as they should, exactly with the same font and position as the original DVDs.
Hmmm, that shouldn’t happen ever with bitmapped subs (the only kind I ever use and would recommend using).
It does. All but one om my movies are with bitmapped subs, and they all have one color that renders as transparent (usually a border or shadow, but often the inside).
External sub/idx files remove this problem, but this works only for files smaller than ~2.5GB per hour (from USB drive). Above this the movie stutters, which calls for embedding the subs again By luck (?) all my BDs have the transparency error in the border or shadow, if it somedays hits the inside text I wíll have to use the M2TS file instead
If the Live plays external subs of the same type and format differently than it plays them embedded then we need to bring this to WD’s attention, Tony, as that sounds like a bug easy to fix.
So we’re saying the Live’s own internal palette is fine, but if it tries to read palette info from an embedded sub it won’t work?
Still sounds like an easy fix (but I’m not so sure you’re right – all the subs I have are internal, and the palette seems to be read just fine. I was surprised the Avatar subs actually appeared in different colors like they do when I play them in VLC whenever the Smurfs are speaking).
I would about bet, though, if you look closely, the borders will be absent. They are absent on my TNG rips, which I believe you say you have access to those DVDs, too?
Seen in VLC, the MKV’s internal subs here show white with black borders.
Actually I don’t have ST-TNG – I’ve rented them from Netflix in the past.
Nearly 98% of my rips are blu-rays and subs don’t seem to have any borders even played in VLC, so the absence of them in the Live doesn’t make any nevermind. But I’m still unsure why the Live would treat an external sub any differently than internal (maybe we can get Guy to explain things to us. Let’s ask in the other place).
Here’s something else that’s interesting: When I extracted the subs to idx/sub files, as I said earlier, I can play them external with the same font, size, color and position. This will work as long as I rename the subs the same name as the episode name. Oh, and the fonts have a black border around white lettering. So, so far so good.
What I then attempted to do was to remove the original subs from the mkv with MKVMerge and re-import them into the newly created mkv file, this, I thought, would fix my problem. It didn’t work. The files still had the same black border with invisible lettering.
What I finally did was, I converted the idx/sub files to an srt file, imported the file into the mkv and…it worked. The subtitles appear as white lettering, but not the same font, size and position. So, somehow the Live will play an srt file embedded directly into an mkv file but not an idx/sub combination of files. Oh, and the shadow was gone too, which would make sense because all the font properties should have gotten dropped in the first place when I performed the conversion from idx/sub to srt.
Anyway, I’m not about to convert over 200 episodes of idx/sub files to srt, that would be crazy. That would take me to the end of the year to convert! I’m happy with the external idx/sub combination of files, just as long as I can read though the dialog when I want to remember a quote from the show.
SUB/IDX are image based; it’s actually a bitmap “picture” and a transparent “Alpha Channel” that allows the movie to show around the lettering. IDX is the “WHEN,” and SUB is the “WHAT.”
SRT is just text inside a text file; the WDTV has to render that into the subtitles itself.
Two totally different beasts accomplishing the same goal.
WD confirms it’s a bug that the titles display differently when put inside an MKV container versus external. Hopefully they will fix it (but I would leave your workflow as is, because WHEN is always a big question mark with it comes to WD firmware).
Tony, thanks for the primer. I really appreciate it!
Mike, I think I’ll leave things the way they are (subs external to the mkv). I’ve been fiddling with this beast for way too long that my iPod Smartlists are feeling neglected! :smileyvery-happy:
Anywho, thanks again for all the help. I’ve got my series converted and I’m just happy that I can play any episode I like without having to crack open the DVD boxes again!
So we’re saying the Live’s own internal palette is fine, but if it tries to read palette info from an embedded sub it won’t work?
No, that’s not the way it works. There is palette data in the external idx file (and maybe in the sub, don’t know), and the Live certainly obeys them. I get 100% correct colors on subs every time (~130 movies) using external files, and I did try messing with the palette a while ago and it went awfully wrong. So the Live USES the specified palette, but makes an error when the subs are embedded.
It was certainly my impression, that this was an old bug, reported long before my time
Cocovanna
Edit: By correct I mean identical to the subs when viewing the original DVD with a DVD player; the differences are subtle and not always detectable when you just view them with the Live. The problem is most annoying with older DVDs, don’t know why
Actually I don’t have ST-TNG – I’ve rented them from Netflix in the past.
Nearly 98% of my rips are blu-rays and subs don’t seem to have any borders even played in VLC, so the absence of them in the Live doesn’t make any nevermind. But I’m still unsure why the Live would treat an external sub any differently than internal (maybe we can get Guy to explain things to us. Let’s ask in the other place).
I am bit puzzled that you don’t see borders in VLC, but actually I might not have tried that. But if you try viewing the original M2TS file with the Live, the borders are present, that is very clear in light scenes (where the borderless subs are hard to read). But I have no workaround for blu-rays, because they require almost always embedded subs too avoid stuttering, so I hope there will be a fix someday.
SUB/IDX are image based; it’s actually a bitmap “picture” and a transparent “Alpha Channel” that allows the movie to show around the lettering. IDX is the “WHEN,” and SUB is the “WHAT.”
SRT is just text inside a text file; the WDTV has to render that into the subtitles itself.
Two totally different beasts accomplishing the same goal.
Except that you might get some font issues with SRT, especially for international characters …
By luck (?) all my BDs have the transparency error in the border or shadow, if it somedays hits the inside text I wíll have to use the M2TS file instead 
