HN user
Digital Media Expert & UX Designer/Developer
https://daiz.moe
I would also be interested in this. Subtitle presentation is something where browsers are still generally very bad at out of the box, so having good subtitle rendering support built directly into the library would make a lot of sense to me. As someone with a lot of knowledge on this subject, I would be very much willing to help at least draft design documents for something like this, if not more.
Been using (and occasionally contributing to) Sharp for quite a while, both professionally and personally. Great library to have at hand when you need to deal with images.
I made some revisions to the start of the article in order to make things more clear to the layman unfamiliar with anime and subtitling. Hopefully that clears things up!
The key to good endnotes is to make them a nice bonus for those interested rather than required reading for everyone. Basically, make the main text work on its own, then get into the weeds of translation details separately. It's the best of both worlds, though admittedly requires quite a bit of extra work to pull off.
Well... the very first paragraph of the article does say with highlighting how "the presentation quality for translations of on-screen text has taken a total nosedive". And then it shows visual examples of the new bad quality and gives comparison screenshots demonstrating good quality shortly after.
Good catch, thanks - I literally built the site alongside the article, so there's still some rough edges here and there.
Unfortunately, as the link describes, Netflix only makes this available for a very limited set of languages, while everyone else is stuck with the extremely limited text-based standards.
Frankly, those text-based subtitle standards are quite maddening on their own. Netflix's text-based subtitle rendering seems to support a much wider set of TTML features than what it actually allows subtitle providers to use - so if these restrictions were to be slightly relaxed, providers could start offering better subtitles for anime immediately with no additional effort from Netflix.
To be more specific, basically all online streaming today is based around the concept of segmented video (where the video is already split into regular X-second chunks). If you only hardsubbed the typesetting while keeping the dialogue softsubbed (which could then be offered in a simpler subtitle format where necessary), you would only need to have multiple copies of the segments that actually feature typesetting. Then you would just construct multiple playlists that use the correct segment variants, and you could make this work basically everywhere.
You can also use the same kind of segment-based playlist approach on Blu-ray if you wanted to, though theoretically you should be able to use the Blu-ray Picture-in-Picture feature to store the typesetting in a separate partially transparent video stream entirely that is then overlaid on top of the clean video during playback.
CR could have used the ASS subs on their website and given the less-dynamic sub files to their vendors.
This is exactly what CR was doing for the past couple years, though you can't just automatically convert a fancy ASS file with typesetting into the limited kind of TTML subtitles that general streaming services expect, which is why Crunchyroll has been paying its subtitling staff extra to make those conversions semi-manually.
Though Crunchyroll could definitely improve its standard ASS workflows in ways that would make that conversion process significantly more automated with minimal extra effort on the subtitling staff's part. It wouldn't even be that hard, I've done something like that myself when I had to mangle ASS into limited WebVTT for some streaming work I did at one point.
This kind of softsubbing is what Crunchyroll primarily does, but it has hardsubbed encodes for devices that cannot do softsubbed rendering of the ASS subtitles that Crunchyroll uses. I go over some ways in how they could do away with these hardsubbed variants in the article without any notable loss in primary experience quality.
Both services explicitly disallow this by default in their delivery specifications, unfortunately.
Netflix: https://partnerhelp.netflixstudios.com/hc/en-us/articles/215...
Netflix requires a non-subtitled version of the content. Netflix defines “non-subtitled” as the presence of main titles, end credits, location call-outs, and other supportive/creative text, but no burned-in subtitled dialogue, regardless of the language in the primary video.
Amazon: https://videocentral.amazon.com/support/delivery-experience/...
Video
Global packaging requires component asset packages to be delivered with a semi-textless video file that can be localized with discrete subtitles and audio dubbing.
Also known as “Texted with no subtitles,” “Textless with main, ends, and graphic text,” and “Non-subtitled”, Prime Video defines semi-textless as a video master without burned-in subtitles, regardless of the language.
Quality typesetting is just as important for dubs as it is for subs, actually! All that on-screen text will be there regardless of which audio track you are using.
See for yourself: https://partnerhelp.netflixstudios.com/hc/en-us/articles/215...
4. Line Treatment
2 lines maximum
Crunchyroll is currently using a subtitle rendering stack that is highly unique in the media industry, being based on the Advanced SubStation Alpha (ASS) subtitle format. It seems that the current executives would like to replace this unique stack with something more "industry standard" (and far less capable), but they can't do that as long as their back catalog is full of ASS subtitles - if they just switched stacks without doing anything else, all of these back catalog subtitles would just stop working completely. Which is why in order to perform such a stack switch, all old subtitles would need to be replaced with worse ones to make them compatible with the less capable new stack.
Lack of closed captions and dubtitles are definitely very real issues as well, though this article is solely focused on subtitles.
I did find instances of them actively deleting old subtitles and replacing them with lower quality ones in the back catalog, yes. Which seems indicative of Crunchyroll wanting to eventually get rid of good subtitles altogether.
The linked article here goes over all of that in great detail!
The cyan is basically just bold, but also a highlighter. I was using just plain bold initially but started experimenting with it and landed on this. Pairs quite nicely with the pink links, IMO.
This is the result of a ton of research into Crunchyroll's recent subtitle changes that have tanked the service's first-party presentation quality to an all-time low. The article ended up being quite long, so I highly appreciate anyone taking the time to read it in full!
If you're going to do script-based video processing in Python, I would highly recommend just going straight for Vapoursynth[1] instead. It's built for the purpose from the ground up, is actively maintained with a decent commmunity and tooling, and isn't tied to ffmpeg's CLI.
Lossless compression means the pixels of the output image are 100% identical to that of the output image.
This site is clearly not doing that, and should thus not be called "lossless compression". The industry term for lossy compression that appears to be basically the same as the source is "visually transparent" or just "transparent". Though this doesn't seem like that either, especially when you're compressing large PNGs into JPGs while naming the output as PNGs. That's just outright deceitful, and not a good look.
As someone who's done made use of most of the techniques listed in these posts, some comments...
First of all, it's nice to see them receive attention outside the fansubbing scene! Anime has long made use of on-screen text in ways that most other mediums don't, and with the limited animation the medium is famous for, it tends to be extremely amenable to localization that aims to replicate that on-screen text presentation as closely as possible. With fansubbing, this is largely due to the power of the ASS (Advanced SubStation Alpha) subtitle format, and the Aegisub editor's capabilities for making use of that power (none of which is a coincidence - ASS was effectively developed for subtitling anime, and the same goes for Aegisub). Of special note is Aegisub's Automation features, which allow users to write Lua scripts to extend its capabilities, even building various extra GUI bits and bobs to make them usable for any non-coders.
To comment on one of the techniques in particular: it's always kind of fun to see people be impressed by masking, because technically speaking it's one of the more simple tricks that people do with ASS. The format includes basic vector drawing capabilities, which can be used to also make clipping masks for subtitles. How masking works is that usually the typesetter will be simply drawing vector clipping masks to clip the subtitles properly, frame-by-frame. Due to the limited animation, this usually doesn't take all that long. If the covering object remains static in shape, you could also just draw the mask once and then use motion tracking and an automation script to move it for the duration of the masked line. So all in all, not very complex, just a bunch of manual effort :)
And speaking of which: one of the biggest innovations of anime fansubbing happened around 2011-2012, when fansub groups started making use of motion tracking en masse. The popular program for doing the actual motion tracking was Mocha[1], and then various tools were used to apply its After Effects -compatible motion tracking data to typesetting lines in Aegisub. This development eventually culminated in Aegisub-Motion[2], which has been the de-facto motion tracking script for Aegisub for quite a while.
Motion tracking is also the main thing still lacking when it comes to typesetting in official anime releases today. This mostly comes down to the fact that while fansubs can have fancy motion tracked typesetting completely softsubbed since they expect their releases to be watched on reasonably powerful PCs, the same doesn't really apply to the much more limited and less powerful subtitle render used by official services. But honestly speaking? That's mostly just an excuse for the official services to not even try. You could have the fanciest on-screen text presentation in the world if you just burned your on-screen text translations into the video (hardsubbing, as opposed to softsubbing). Yes, this approach would work just fine even for multiple languages - modern video streaming is already based on short segmented chunks, so all you'd need to do is develop a system that will make multiple hardsubbed variants of only the segments where on-screen text is actually present. With this, for the vast majority of video, you would only need one variant. I developed the bones of a system like this myself for some official anime streaming I worked on some years back (unfortunately no longer available), and it very much was extremely feasible. This kind of segmented hardsubbing is even possible on Blu-ray, so the technique is disc-feasible too.
In conclusion, I completely, 100%, concur that I'd love to see a lot of these techniques be used with official anime releases. Especially since it would be very much possible to apply just about all of them as long as a publisher was simply motivated enough to make it happen.
As someone who has built custom EPUB authoring scripts in Node.js for work and also quite likes the EPUB spec: cool! I expect I'll still keep using said scripts for work, but I have some side project ideas which would involve actually reading EPUB files too - I'll probably give this a spin for those.
Extremely welcome legislation, especially since it has an exception for "permanent download that can be accessed offline", ie. DRM-free downloads. It's about time someone actually calls out Big Media on their deceptive practices. As I've been saying for years, it's not "buying" with DRM-encumbered media, merely "renting for an undefined time period".
In fact, it'd be even nicer if the legislation explicitly required rental terminology to be used for anything DRM-encumbered, but well, even as-is, this is an extremely welcome development and I hope legislators worldwide are taking note and plan to follow suit as soon as possible. This kind of victory for digital consumer rights has been long overdue!
I've yet to meet a single developer who likes what Apple did with 100vh. And it's why all my projects to date that want to use viewport height in CSS have ended up adding a JS snippet that sets a --vh CSS variable to window.innerHeight on resize, because I have no interest in dealing with Apple's special boy CSS behavior. And really, even Apple itself admits that their 100vh solution is troublesome - they wouldn't have introduced all these new units otherwise! Even if the saner solution would have been to just change their idiosyncratic 100vh behavior to what developers actually expect from it.
Gotta say, really disappointed with the fact that instead of Safari making 100vh actually mean 100% of viewport height like it's supposed to, they instead present us with all these new viewport units, all to fix a problem that was caused by their own deviation from the spec to begin with. And of course they're not going to do anything about 100vh even with all these new units, because how else are we going to force developers to use our special units to cater to our browser's quirks!
I did see the beta calendar. It's a start for sure, but most back catalog titles still have zero information in terms of when to expect new chapters for them, so there is definitely still work to be done in that regard. And on the calendar itself: entries should ideally be grouped by day. Multiple entries for the same title on the same day should get grouped to one entry (so eg. "Again!! c74-76" rather than "Again!! c74" "Again!! c75" "Again!! c76"). And this one's especially important: if a user is logged in, the calendar should highlight titles in My List by default, and you should also be able to filter the calendar to only show My List titles. For an external reference, I can recommend taking a look at J-Novel Club's release calendar, as it covers basically all of these points and then some: https://j-novel.club/calendar
On the subject of apps, I'm not saying you shouldn't have apps, I'm just saying that there are certain things you should share across the web and apps, like the reader. Basically, you could have the reader running in a web view inside the mobile apps, and this way you could have just one reader codebase that gets reused across all the platforms. You could take this even further and build your mobile apps with web tech inside web views as well. You probably wouldn't do that at this point, but I would still recommend looking into using the reader in a web view at least, as that's no doubt the most complex frontend component in the entire system.
I've done a couple impressions threads since your initial launch last year[1][2], and it's nice to see that there's been some improvements in regards to matters brought up in them, though there's definitely still room for more. The reader in particular is still rather janky and lacking in options (I would really like to see more fitting options than just forced fit to height as well as manual control over image quality) and the controls aren't great either - for example, trying to rapidly click forward with mouse works poorly because the click regions are image dependent rather than constant so the animated page transitions makes clicking in the same area unreliable. And speaking of transitions, it would be nice to have control over the speed of them, including making them instant. The current speed is slower than I'd like and it's a constant source of annoyance.
And while you've increased the image resolution since launch, there are still notable problems with the overall image quality. Some series have horrible looking screentones (like Domestic Girlfriend as a random example I just found) while others have incorrect black levels (black isn't RGB 0,0,0 but instead something like ~36,31,33)- The World of Summoning being one recent example. I know that in some cases you might have screentone issues at source level but manga is something where you have to really know what you're doing in terms of image scaling to not mess things up further, as screentones are incredibly fragile and easily turn into an ugly mess when resized.
One thing that I'm decidedly not happy with that you've done after launch is the exclusive streaming deal you made with Kaiten Books a while back. The manga distribution market has generally been one of the few bright spots in the area of Japanese media where things are not exclusive by default and customers can actually have real choice and preference in terms of where they get their manga from. In other words, competition that's actually beneficial for consumers, the same which can't be said for eg. anime streaming services where the only difference is in which service has what shows, which does not benefit the consumer in any way. I would be more understanding of exclusivity if Azuki actually did in-house licensing and translation, but signing exclusive distribution deals with a third-party publisher just comes off as trying to pull up the ladder after yourself to the benefit of no-one but yourself. This is a sincere plea from me: please keep any possible future exclusives to in-house licenses at most, please. The world does not need any more anti-consumer exclusivity than what it already has.
Seriously, it's not a problem especially for manga subscription services to share the same content. If there's multiple places to read the same things, then I can choose the one that offers the best service, and while Azuki has issues, I do think you have potential too. The only real problem with shared content isn't the sharing itself but rather Kodansha, the publisher that shares its content the most, and their goals in sharing, which seems to be to primarily selling ebooks rather than letting consumers actually read their series in full via subscription services. That's really the primary problem for the subscription services to tackle - actually having series to read in full. This is why I also see the calendar features I talk about in the Twitter threads as so important - if a back catalog series isn't fully available, then it's really important to be able to see when I could expect it to be, because I sure don't want to be stuck as a subscriber for months only to see new content for a series I like come out once in a blue moon, if ever.
Going back to more technical matters - I do have to wonder, what made you decide as a small team that you'll build entirely separate versions on three platforms? Having built a web-based manga reader professionally myself, I know that it's not an easy task to develop an actually good one, and you've essentially made that three times harder with separate codebases for every platform. At the very least, I would recommend only focusing on the web tech reader and reusing that across the platforms, as right now the burden of 3x development is really showing with how a web can get a feature and then we'll have to wait months and months for one of the mobile apps to get them and then even longer for the other to get it too.
Anyway, that's all that I can bother to write for now. I do intend to make another Twitter thread on the service at one point - maybe in three months at the one-year mark?
There absolutely isn't a labor shortage with translators. There's plenty of talent out there, it's just that many are not willing to work for the peanuts that big companies are offering so they end up doing something else to get by instead. If the companies tripled or quadrupled their current rates, many who have abandoned the field in the past due to poor compensation would jump right back in.
We had a good demonstration of the above here in Finland a while back. There's been a lot of talk here about a "nurse shortage", but the reality is that most places just aren't willing to pay nurses well. When an individual company announced an opening for nurses with way higher pay, they were flooded with qualified applicants - many which came from people who had quit nursing previously due to poor pay.
This article was widely derided among translator/localizer circles, because the true fact of the matter is that the only thing causing "shortage" is that the pay is shit. A lot of the article here builds up on statements by David Lee, the CEO of Iyuno-SDI, and even the article mentions the fact that his company pays its staff terribly:
Last year, several major European translator associations blacklisted Iyuno-SDI, discouraging their members from working for the company due to increasing cuts to their freelance subtitling rates.
Anyway, besides the long-standing general disrespect toward the importance of localization, one of the big things driving down rates that has come along recently is the practice of "machine translation post editing" (MTPE for short), where a company first uses machine translation to produce an absolute garbage of a script (because translating fiction is simply not going to work out without an actual intelligence to drive the process) and then hires a translator who will usually need to pretty much redo the entire thing to get something good out of it. But hey, because they're only "editing" an existing script, that's enough justification to slash the already bad prices to basically nothing!