Daiz

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?

[1] https://twitter.com/Daiz42/status/1409670066925228035

[2] https://twitter.com/Daiz42/status/1428413172516544512

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.

> 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!

And as mentioned, I don't put much trust in kernel anti-cheats in general, which is a big reason why I primarily play single player games. Which is why I'm extremely annoyed that a single player game that I might otherwise play comes with a kernel-level always-online DRM, all to protect the sanctity of predatory lootbox gambling monetization.

I would say that isn't really true. To play Genshin Impact on PC, you are required to install kernel-level always-online DRM on your computer. And the kernel anti-cheat (which exists solely to protect the integrity of their lootbox gambling monetization and has zero benefit to players) isn't even one of the usual ones like EAC or BattlEye (which I personally don't have much trust in either, for the record), but rather one developed in-house by the game's Chinese developers. And considering how involved the Chinese government is in the local game industry, that means you could effectively be giving the Chinese government kernel access to your computer in exchange for being able to play Genshin Impact. That's a pretty heavy price to pay in my books.

And of course, because the integrity of the gambling machine is the ultimate priority, things like modding and other popular single player pastimes are completely out of the picture as well. And because it's a live service game, every single penny you put into it will eventually be lost to the void as servers are shut down and nobody will ever be able to play the game again.

I'd be happy to pay for Genshin Impact as a regular single player game with no lootbox gambling mechanics that I could play offline without DRM and do whatever the hell I want with it after purchase without having to worry about a built-in killswitch disabling the game one day. But as that is not the reality we live in, I'm fairly certain I will never be installing the game on my computer, as the price is simply too high.

It's been around for ~9 years and has a relatively large community around it, most visibly found on the Doom9 forums: http://forum.doom9.org/forumdisplay.php?f=82

I'm personally still mostly using Avisynth these days since it's what I'm most familiar with, but I've also used Vapoursynth and it's definitely the one to learn if you want to get into programmatic video processing these days.

https://daiz.github.io/yuv-to-rgb-in-html5-video/

Sad to see that even today the results don't line up with the expected... and in different ways than before, even?

Something the article doesn't touch upon is that colorspace assumptions can also vary between different video formats across browsers (at least back when I made this test), which adds another unfortunate dimension into the color accuracy mess.

Anyway, good to see more attention brought on the subject once again, though unlike the article, I would personally say that if we're going to make assumptions in the absence of concrete colorspace information, I think we should rather consistently assume BT.709 rather than BT.601, for the simple reason that we can reasonably expect that basically any camera in existence today would likely record in BT.709 by default, and I'd expect most editing software with their HD presets and whatnot to default to BT.709 as well.

[1] A related comment I wrote on HN about it back in the day: https://news.ycombinator.com/item?id=12022163

Namely, I just wanted to keep track of what I read. I didn't care for the social aspects of it nor the discovery part of it. I did want certain statistics on my reading though, so a plain text file wasn't going to cut it.

Unfortunately, Goodreads was a huge pain to use UX-wise and didn't really provide the statistics I was looking for either. The one positive thing I can say for Goodreads is that the books I read were already there (I'm primarily reading Japanese light novels, so whether the titles are available on the service for tracking purposes or not is a real concern for me), which is probably a bigger problem than you might think for anyone who'd want to build a competitor? The friction to use an alternative service is obviously going to be much higher if you have to get the books you read added to the service first before you can actually track them on your list.

Anyway, with my sufficiently narrow use case, I just built my own book tracking with spreadsheets. I add new lines to a master read sheet and then I have some pivot tables that automatically compile statistics I care about from there.[1]

I'm quite happy with this setup for now and can definitely recommend doing something similar for everyone who just wants to keep track of your reading and doesn't care for the social features.

That said, I wouldn't mind switching to a "real" service again provided that a) it was sufficiently expedient to use when it comes to managing your list (this is especially important considering I'd obviously want to port over my existing hundreds-long read list to this new hypothetical service) b) it already had the books I've read catalogued in the service, because I sure as hell don't want to petition additions to their database for everything I read before I can actually keep track of it.

[1] https://twitter.com/Daiz42/status/1158123020596240391

Anime4K has even less going for it than waifu2x does, it's pretty much just simple warpsharping with a fancy marketing name.

Neither of these are particularly interesting as far as upscaling / remastering goes, and I'm saying that as someone who has done SD to HD anime upscaling/remastering projects from SD masters myself. And while you can get results that look pretty solid for the most part, it is ultimately still going to look like an upscale when compared to native footage. Here's a comparison with two examples:

https://slow.pics/c/wNZKk3WQ

As you can see in the second example, the upscaled nature of the SD to HD conversion is especially clear in areas where the lineart has been very tightly packed originally.

HTML DRM is antithetical to the Open Web itself. It was built on a sham of "plugin-free" media playback, but all we did was change Flash and Silverlight for a whole range of closed black boxes, which in turn are effectively all controlled by Big Media (to make it crystal clear: EME was built with third-party decryption modules in mind, and Big Media was obviously never going to support any sort of decryption modules that they couldn't control, so even if your custom browser supports EME it's completely useless without a Big Media-approved decryption module). And make no mistake: Requiring permission from Big Media to essentially build a fully-fledged browser is a 100% intended and expected outcome of HTML DRM as conceived. Big Media would love nothing more than to turn the entirety of the Open Web into Closed Web that they control, and with HTML DRM they've certainly achieved a great step toward doing so, to the detriment of public at wide. I'm sure they're positively salivating about the thought of eventually reaching The Right to Read![2]

[1] https://news.ycombinator.com/item?id=7747142

[2] https://www.gnu.org/philosophy/right-to-read.html

Tough luck with that though since EME only specifies how to communicate with DRM, and the actual DRM consists of multiple 100% proprietary black boxes that only work on blessed end devices and browsers. And since different browsers have different black boxes, you need to play ball with Apple, Google, Microsoft, and every other unique DRM vendor.

EME is a disgrace that should have never come to pass. Premium media should rather be forced to peddle their own clients entirely separate from browsers if they insist on non-cross-platform black box bullshit.

I'm not against content protection in itself, but EME was 100% marketed on false pretenses because it's just as much of a proprietary plugin system than what came before, with just as terrible cross-platform story too. If instead we had content protection schemes implemented in eg. WebAssembly, then we could actually talk about a cross-platform system that also doesn't immediately close out smaller browser vendors from the market.

For example, my desktop with an i7-2600k (that's a Sandy Bridge CPU from 2011) has zero issues playing 4K60 VP9 footage on YouTube in Chrome with CPU decoding, yet on Netflix with the same Chrome I'm arbitrarily restricted to 720p H.264 video.

    /**
     * adds 42 to the input number
     * @param a the first number to be added
     * @param b the second number to be added
     */
    function ADD42(a: number, b: number): number {
      return a + b + 42;
    }

It inevitably invites comparison though.

>We did not observe as many free edition conversions to paid as we would of hoped with C2.

I can understand that, and I wouldn't mind it at all if C3 was also a one-time purchase like C2 (if that was still the case I'd be buying C3 in a heartbeat), but I definitely think it's the wrong way forward with the change in the payment model. I have a bunch of small C2 projects from over the years I've used the program, and I can go back and edit them with C2 even today. However, if I got a C3 subscription for a year and upgraded my projects to C3, then a year later when my subscription ran out my projects would suddenly become essentially read-only due to the free edition limitations, and this whole thing of effectively locking me off from my own projects just completely kills my interest in the current free/paid model of C3. (I'm not actually sure how Unity handles this same scenario, but seeing how the free version still offers the fully-featured engine and how the tiers differ, I'd expect the story to be much better there.)

>Worth mentioning is that we're planning on selling C3 for ~$99 USD per year, if you want all the Gamemaker export options you'll spend > $1,000. I feel in comparison to that, our pricing is still competitive.

While that's true for Game Maker Studio 2, you also have to consider that both Clickteam Fusion and Game Maker Studio 1 have shown up in several Humble Bundles for practically pennies at this point. I actually own both CF2.5 and GM:S along with the most important exporters available for them (Desktop/iOS/Android/HTML5) and I only paid $15 for each (and I bought both because I wanted to see how they stack up against C2 today, which cost more than both combined). From usability and performance standpoints I don't see GMS2 being that big of an upgrade, so sticking with GMS1 would certainly be a viable option for anyone interested in it as an alternative.

>And, as you put it, we are wiping the floor with the competition so we feel reasonably comfortable at this stage experimenting with a different pricing model.

Well, sadly as much as I like Construct as a 2D game IDE, it pretty much kills the program for me and also makes it way harder to recommend to other people as well, which is something I've done a lot with C2 over the years (I got a lot of people at my uni to use it and know several people who ended up buying personal licenses as well).

Personally I think you could expand the free version and make the paid version more expensive. If I ever get around to doing commercial products with Construct, I certainly wouldn't mind paying more than $99 a year for a paid version, even if it was just to get rid of splash screens. You could also take cues from how Unity differentiates the tiers in other regards, like with the cloud build queue priorities and multiplayer support etc (if you're using Scirra-provided infrastructure).

Well, you should, because both C3 and Unity using a subscription model vs the one-time payments of many other options makes it the most direct comparison. Both concretely and psychologically a subscription model requires a much more serious commitment to the product compared to a one-time payment.

And beyond the payment model, I've long thought that Construct offers a serious alternative to Unity for serious development purposes if you're making 2D games, and in fact I'd say in many ways Construct has the edge over Unity in this space since it's built for 2D development from ground-up whereas Unity is a 3D engine first, which makes 2D development in it more cumbersome. This is why I was happy to see you mention in another comment that you intend to shift the marketing of C3 to a more "serious" direction, where C2 often gave the impression of a "toy". But that's just another reason why you should consider yourself as a serious alternative to Unity yourself.

I assume that the "direct competitors" you're talking of are along the lines of Clickteam Fusion and Game Maker. It's certainly true that these are both 2D-focused game IDEs, but both are sold as one-time payments, much like C2. As someone who moved from Multimedia Fusion 2 to Construct 1 back in the day, I personally think C2 has already been the king of this space for years, wiping the floor with the competition when it comes to both usability and performance as well as scaling to big projects. This is why I'm not at all fundamentally opposed to "going bigger" with a subscription model to compete against other subscription model game IDEs, because I believe C3 is very much capable of competing in this space, all the while having a lower barrier to entry. But again, to be competitive here, things should really change with the way the free edition is handled.

Ultimately right now Construct 3 falls into a very uncomfortable position where I would never want to downgrade to the likes of Clickteam Fusion (neither the current 2.5 nor the upcoming 3) or Game Maker Studio 2 (because they are both less powerful/performant as well as less usable on the whole and scale big way worse), but I honestly wouldn't want to use Unity either because while power-wise it's definitely capable I'd still be somewhat of a downgrade in terms of usability for 2D development (I have actually used Unity for a couple projects in the past, but I've stuck around with Construct 2 for this exact reason). As a professional programmer there isn't really any insurmountable obstacles to using any of these programs for me, so it's all about the convenience for me, and 2D development with Construct is where I believe the sweet spot lies in this regard. But as it is, C3 free edition is just too restricted power-wise and the subscription is too big of an investment. Because of this I also see myself having a hard time recommending C3 to other people in the future, where recommending C2 used to be a no-brainer.

However, as things are right now, it seems that the time has come for me to part with Construct. I do web development for a living, and game development is something I do for fun on the side mostly for my own enjoyment these days. The limitations of the C2 Free Edition were too much for me (as a programmer even my tinkering tends to be event-heavy, and even my smallest toy projects tend to start with creation of more layers than what's available in the free version), but this wasn't really an issue since the Personal License was simply a one-time investment, and I've been very happy with my purchase.

However, with the move to a subscription-based payment model, this changes completely. I can't justify paying $99 a year for how much I use the program. The Free Edition is also not an option because it seems to be even more restrictive than the C2 one. This is extremely unfortunate from a personal standpoint, and I'm clearly not alone with this opinion, seeing how much negative feedback the move to subscription model has garnered on the Construct forums.

But there is also the business standpoint to consider. The one-time payment was a huge pro for C2 and more than made up for the restrictions of the free edition in my books. But now with the move to a subscription model you're competing more directly with the likes of Unity that also uses a subscription model. And if you look at what Unity offers in the free tier[1] and compare it to Construct[2], the latter looks like a complete joke in comparison. With Unity, you get a full-featured engine with all the export options that you can make money with (with a revenue cap after which you need to upgrade, similar to C2 Personal -> Business), with the most notable "downside" basically being a "Made with Unity" splash screen. Something like this is what I would expect to see with the C3 Free Edition as well in order for it to be truly competitive. After all, game IDEs don't exist in a vacuum.

[1] https://store.unity.com/

[2] https://www.scirra.com/store/construct-2

As long as anti-circumvention laws are a thing, the real answer should be nothing but a very enthusiastic "no". I don't see how anything covered by anti-circumvention laws could in any way be compatible with the idea or spirit of what is supposed to be Open Web.

>The reason for recommending EME is that by doing so, we lead the industry who developed it in the first place to form a simple, easy to use way of putting encrypted content online, so that there will be interoperability between browsers. This makes it easier for web developers and also for users.

This is also a whole bunch of horse manure considering that the actual DRM part is externalized to proprietary black box extensions so in reality HTML DRM doesn't really do much to improve interopability. A browser vendor needs to basically bundle a black box extension with their browser to handle the DRM, and the DRM needs to approved by vendors like Netflix etc in order for you to actually view DRM'd content on their site. Basically this just entrenches the dominance of existing browsers over the market while making it even harder than before for anyone new to try to tackle the market since now you need to basically please Hollywood if you want to be able to play their content in your browser, all with the blessing of W3C.

Sure, these DRM solutions already exist and will continue to exist, and it doesn't help that two of the three big browser vendors are also DRM vendors themselves (Google & Microsoft), but the last thing we should do is give them official blessing for their practices. It's a huge spit in the face of the Open Web.

EDIT: Some more comments.

> If EME did not exist, vendors could just create new Javascript based versions.

This would be an infinitely more preferable solution to EME, because guess what - this would actually guarantee true interoperability! As long as your browser could run (modern) JS, it would be compatible with a JS-based content protection scheme. Things on eg. Linux would Just Work without having to use rely on Widewine DRM on a closed build of Chrome, for example. So presenting EME vs JS-based protection schemes as equivalent is ridiculous. The latter is vastly less bad than the former.

>And without using the web at all, it is so easy to invite ones viewers to switching to view the content on a proprietary app. And if the closed platforms prohibited DRM in apps, then the large content providers would simply distribute their own set-top boxes and game consoles as the only way to watch their stuff.

If content distributors wanted to try and ignore the web completely in the name of "protecting their content"... by all means, go ahead! Somehow I suspect they wouldn't resort to that, though - they wouldn't be so interested in HTML DRM if they didn't see the web as a valuable venue. Most likely they'd end up restricting web versions to lower quality options while trying to lure people to more closed enviroments with promises of higher quality, but the thing is that they're already doing exactly that anyway even with all the black box DRM they have today so it really wouldn't be all that different from that.

>An important issue here is how much the publisher gets to learn about the user.

This whole list is also ridiculous considering that proprietary black boxes are a way bigger unknown in terms of what they could be doing on the user system than any say, JS-based solution. And the "user tracking" the DRM supposedly couldn't do could be done separately in JS anyway, whether the whole content protection is based on JS or not, so this list is once again basically just a poorly thought distraction.

>Spread to other media

This section is way too short and basically handwaves the issue away. "Music probably won't go back to DRM and books, lol dunno, maybe they'd give up DRM even when we're explicitly endorsing DRM for the web?" Endorsing any kind of DRM in HTML standards has a very real danger of being a slippery slope. Hey, now we can black box DRM <video>. When can we do it to <audio>? Music and audio in general needs protection too! Hey, we got it for <audio>, now where's our DRM support for <img>? Images need to be protected too, they're copyrighted content after all! And what about text? Books and articles need protection too! <p> needs DRM! And suddenly the DOM in your developer tool is just a bunch of black boxes, and the Open Web is no more. In fact, developer tools in general should probably be banned, someone might use them for anti-circumvention purposes after all, and that would be illegal! The Right to Read[1] is uncomfortably real with the possibilities here.

>Despite these issues, users continue to buy DRM-protected content.

Well gee, it's not like legitimate users have much options in many cases. Video especially tends to be DRM-infested pretty much everywhere you go. In many cases piracy is literally your only option when it comes to getting content DRM-free, which is a crying shame. This is once again no reason whatsoever why we should just be okay with it and endorse DRM for what is supposed to be Open Web.

>The web has to be universal, to function at all. It has to be capable of holding crazy ideas of the moment, but also the well polished ideas of the century. It must be able to handle any language and culture. It must be able to include information of all types, and media of many genres. Included in that universality is that it must be able to support free stuff and for-pay stuff, as they are all part of this world. This means that it is good for the web to be able to include movies

Well, I completely agree with that...

>and so for that, it is better for HTML5 to have EME than to not have it.

...but this does not follow In fact, it goes pretty much directly against it.

[1] https://www.gnu.org/philosophy/right-to-read.html

It really is sad how often legal digital products are inferior in quality to their physical versions, even though with digital you could pretty much always offer more than what the physical formats allow.

Also, another common scourge of digital distribution that Bandcamp doesn't suffer from: region locking. They don't support it and don't intend to do so either: https://bandcamp.com/help/selling#region

Basically, if the Result doesn't match up with Expected, the browser is doing it wrong. Ideally browsers should handle YUV colorspaces like so:

H.264 video - look for colorspace tagging in the video by default and use it if available, otherwise fall back to guessing based on resolution. SD video (up to 1024x576) should be converted with Rec.601, HD video (width >1024 or height >576) with Rec.709.

VP8 video - VP8 is defined as Rec.601 only, so always use it.

Theora - Same as VP8.

How browsers actually fare today (tested on Windows 10):

IE11/Edge - Always assumes Rec.601 for H.264 video. Doesn't support VP8/Theora.

Chrome - No colorspace tagging support for H.264. Converts HD video with Rec.709, SD video with Rec.601. 1024x576 is treated as HD already. VP8 is always converted with Rec.601 as it should. Theora gets Rec.601 in SD but incorrectly uses Rec.709 in HD.

Firefox - No colorspace tagging support for H.264. HD uses Rec.709, SD uses Rec.601, 1024x576 treated as HD like in Chrome. VP8 and Theora both always use Rec.601 as they should.

The unfortunate conclusion from this is that color accuracy is pretty much a crapshoot when dealing with HD video on the web. The only way to guarantee accurate results right now would be to convert your video to Rec.601 (if you're mastering HD video chances are you're using Rec.709 by default), serve VP8 video by default and have a Rec.601 H.264 fallback for IE/Edge (I haven't tested how Flash video playback handles this matter so you might also need a Rec.709 H.264 fallback for that).

There are also other issues with this, like how resilient the scheme would be. If your watermarking relies on things that the user would hardly spot when watching, then it's very likely that re-encoding the video would simply get rid of the watermarks, since quality video compression is generally based on the idea of throwing away as much information that the user wouldn't notice while keeping as much important bits as you can. At the same time, if you make the watermarking easy enough to spot while looking carefully, then you could just have two people compare their watermarks and consciously mess them up.

That being said, various kinds of watermarking technologies do exist, but unless they're dynamically added to the content on playback they should all very much have the same kind of scaling issues as far as video encoding is concerned.

[1] Once in all the varying quality and compatibility levels you offer, anyway.

As long as it isn't trivial for the casual user, I wouldn't call it much of an issue. As I said, dedicated pirates will find a way regardless, even if comes down to screen capturing. That's how people are pirating Netflix content at the moment. Of course, this does lead to some level of quality loss, since you're doing a lossy re-encode of a lossy source.

On that note, if we consider "wannabe pirates must re-encode the video to share it around" as a decent video content protection goal, then you can definitely do that with HTML5 video and some JS without resorting to any kind of EME trickery.

Anyway, at the end of the day, it is definitely true that JS content protection schemes will be inherently weaker compared to black box DRM plugin solutions enabled by EME. But why on Earth should we compromise the very nature of Open Web to enable this rather than make Big Media compromise on their platform control addiction to have their content on the Open Web? And if they're unwilling to do that, then well, they can stick to their Flash and Silverlight all they want in my opinion. EME doesn't make any promises about cross-platform compatibility anyway, so better stick with the two devils we know than switch to a system comprised of several unknown demons.