Really wish they would do standard h264 encodes like DoA or JPTVTS. Those HEVC files are truly annoying (they actually look worse than an equivalent h264 encode, like some sharpness is missing or an extra blur filter is added on top, need tons of extra CPU to play back, so the fans spin up on my Mac; can't play them back at all on my actual TV machine/ Raspberry PI 3, so I would need to re-encode all files for that use case) Just some feedback to the encoder here… please do standard h264 (crf18?) encodes (too) for better compatibility. That would be awesome! :)

> Do like DoA or JPTVTS This is terrible advice. Neither of those know how to encode and everything they touch looks like shit.

I would like to see x264 as well. Not all software can handle x265. If I were to use your files when timing subtitles, I'd have to re-encode the videos myself. I'd suggest you release 720p and higher in x265, and a lower resolution is x264. If you think 480p is too small, then maybe 960x540p? Then everyone would be happy.

DoA or JPTVTS looks like shit? What the heck are you talking about? These two encoders are the best around. They actually know what they're doing. Like it was previously said, x265 is a pain to handle. My computer can't play it smoothly, so if I had to sub a drama with these files, I'd be screwed. Also, never saw a x265 encode that actually looked better than the same x264. I remember AoZ files very well. My TV can play them fine so I can compare and know what I'm talking about.

If you want x264, you're welcome to use this alternative: https://nyaa.iss.one/view/1293581 Also, for your reference, you can use this wonderful tool to retime subs across different encodes/sources: https://github.com/FichteFoll/Sushi

@riker: that's a webrip, not an encode from a TV cap source. @tjorna: what exactly do they wrong? Do you have any recommendations what they could fix? I do h264 encoding for myself and would like to learn too. While both groups (DoA and JPTVTS) had some releases with issues the general picture quality is usually very high for 720, IMHO. So I really would like to known what they do wrong in your opinion? :) @keiko1981: 720p in x264 and x265, 1080p in x265, 480p in x264 and everyone is happy. :)

> like some sharpness is missing or an extra blur filter is added on top You have to look at the source video to make any justifiable claims about visual quality. NTV, for example, is well known for drama broadcasts that look soft and there's nothing an encoder can do to fix that - the encode will be just as soft as the original video. I took a look at this video and it looks visually identical to the raw HDTV cap I found. Also, if you look at the mediainfo you'll see that it was encoded with crf 23 which, for x265, is labeled by the spec as "visually lossless." > need tons of extra CPU to play back, so the fans spin up on my Mac I guess you're using an old mac? Or, you don't have your video player setup correctly to use hardware decoding (either the Intel QuickSync decoder or the nvidia NVDEC decoder) - but if you do that you should see CPU usage drop (assuming you have nothing else going on in the background). x265 Hardware decoding is build in to Intel CPUs and nvidia GPUs for many years now. As for RaspberryPi3, well, it's not designed as a dedicated video playback machine. Get an AppleTV or a cheap AndroidTV box - those all have been capable of hardware x265 decoding for years as well. > That's a webrip not a TV rip encode Beggars can't be choosers. If you want x264, you have options. Or you can encode it yourself and contribute back to the community instead of complaining and acting so entitled.

DoA as a group has rules and standards applied to all releases. JPTVTS is a collection of disparate encoders who all use different settings and have no body to enforce standards. Thus you cannot make a blanket statement about JPTVTS quality, but you can about DoA. However, DoA is known to be high quality. If you want to learn what DoA does just look at the settings in the mediainfo from their releases. It's not too hard to "reverse engineer" the settings from there but it will require you to learn about x264 encoding options. What you won't find in the mediainfo are the filters they apply to the video stream. Specifically: what they use to resize and deinterlace. But I will tell you that they use one of the most compute intensive deinterlace filters which is why they can claim that they have the "best" quality. Other encoders do not spend time using that deinterlace filter and use a faster one that gives good results. But if you were to compare, that's where you'd find the major difference.

Also, perhaps you didn't know but 4K BluRay uses HEVC (x265) as its codec, so your claim that x265 codec adds blur, reduces sharpness, or visually inferior is pretty bogus. https://en.wikipedia.org/wiki/Ultra_HD_Blu-ray And, your request to encode every episode 4(!) times for each show an encoder is working on is not feasible and comes across as entitled. I encourage you to spend time learning about encoding and contribute back to the community rather than leeching and complaining. Put up or shut up, as they say. Oh, if you do actually encode, please know that if you bring something encoded in handbrake [because the default audio codec is shit] or with QuickSync/NVENC/etc. after having made claims about the quality of this encode, you will be laughed out of the room for demonstrating your ignorance. P.S. if you want to produce a video with AVC (x264) that is similar in quality and size to HEVC (x265) make sure you're using slower preset. If you thought your MacBook fan was having trouble before, wait until you try that. Perhaps then you'll show some gratitude towards the effort that others have made to the community. P.P.S bonus points if you try to use QTGMC deinterlace filter like DoA does! You'll figure out why once you try it.

Hi! To add to riker's point, I have tested some x265 encodes I obtained from a 720p x265 encoder I follow on a somewhat legacy device, it is a Macbook model from the late 2012. I faced no such issues that were mentioned with some basic testing of skipping around the video and trying various TV shows encoded to 720p x265 from a tv capture, blu-ray, et cetera. The VLC in that Macbook of mine is outdated, I haven't updated it (VLC) since 2019 yet there were no issues of fans spinning up even though the battery on that Macbook is leaking from how old the model is, the fans only spin up when I play a video while charging which may be a contributor to the battery leaking, though I do not mind since it's still fast for its age and I have a PC where I do nearly everything on, so I have mostly ditched the Macbook and only use it when I have to travel but need access to a laptop for important things. I have not serviced that Macbook even once so it's really worse for wear. As an encoder for the same site, please do not ask to request something unfeasible as riker has said. We, the encoders, simply do not have all the CPU power to encode something 4 times just for one episode, and to put it in a way: it is an unreasonable demand. The tracker (JPTV.Club) provides 1080i raws for anyone to download and save and even share! We do not lock these 1080i files to our tracker at all :) In fact, we want those 1080i files to be used and being kept safe by the downloaders :D

So if you are not satisfied with our encoders you are free to save the 1080i ts file which is the direct HDTV capture with CMs intact and untouched. You are also very much welcome to encode a version for legacy users from the 1080i file. As riker said, please take the time to learn actual encoding. Encoding with Handbrake or any basic GUI encoder is not what I as an encoder would classify as valuable encoding experience. What I would classify valuable experience is the understanding of how to use ffmpeg, Avisynth, Vapoursynth, and filtering with either one of those three or even piping an Avisynth script through ffmpeg to encode. There also is the experience of determining which audio codec is the best for an encode, as riker is very correct: Handbrake's default AAC encoder is so bad that you might as well ditch the program for another alternative: MeGUI which gives you the option to use QAAC and a self built FDK AAC, and Hybrid which has FDK AAC directly built in. Or find a way to build a custom version of Handbrake with FDK AAC which I currently have installed. Japanese HDTV captures are not the greatest in quality, and we simply do not have the time to encode with QTGMC like DoA does. So I am hoping that everyone understands.

Now i feels like I got retaught all the things already knew. :) And who the heck re-encodes audio (unless there's an error in the source than needs to be fixed) Maybe you simply could ask your JPTV.club users in a vote what they prefer? It just feels weird you ignore opinion of well known fansubbers and long-term jdrama supporters like keiko1981 and Gabrielmpf, f.ex. and exclude a whole bunch of people from enjoying your drama releases and/or force double work. Of course if the encoder has a preference then that's that. :) But a vote would be nice and should give you some sort of extra feedback too. Anyway… I just leave this here to visualise my point: https://i.postimg.cc/rVGw31Dy/foobar.png?dl=1

What is that screenshot? It's not this show, not the encode we're discussing. If you allow us to pull in whatever we want to prove a point then I can point to some shitty x264 encode. Also, you aren't even using the same frames in your comparison! They may be the same frame # relative to their video file, but each encoder has trimmed the CMs from the source file slightly differently thus the same frame # will not actually contain the same image. You can tell by the subtle differences in the position and direction of the person's face in the foreground, and the location of the person's head in the background. Talk about specious arguments. For as much attention as you paid, I'm surprised you didn't notice. In any case, it sounds like after being told your video player is misconfigured thus your problems, your argument boils down to preference. That is perfectly fine. But why do you claim that Keiko's preference is the guiding light -- they're an SD re-encode fan and obviously prefer old file formats and smaller video for old, low-end systems. Hardly someone representative of "the community." And if it's about who "supports" the community more, well, whoever encoded this (not I) is doing a lot more to support the community than you are (where are you encodes?). I took a look at several of the recent x265 drama encodes posted to nyaa and they have several thousand downloads with no complaints about codec (save for yours) so I don't see where all these people that you claim are excluded from enjoying drama are. But if they do exist then again, alternatives that align with their codec preferences exist: https://nyaa.iss.one/view/1293581 -- or they can download the raw and encode it exactly how they like and share that back with the segment of the community that shares their preferences. It's an open world!