[NeoLX] My Hero Academia (僕のヒーローアカデミア) - S07E14 (152) [1080p x264 10bits AAC][Multiple Subtitles].mkv

Anime Tosho Home » Boku no Hero Academia (2024) » 14, Together with Shoji »

[NeoLX] My Hero Academia (僕のヒーローアカデミア) - S07E14 (152) [1080p x264 10bits AAC][Multiple Subtitles].mkv

Source Links

AniDex | Torrent Download | Magnet Link (1.335 GB) | NZB

Date Submitted

24/08/2024 14:22

Series (!)

Boku no Hero Academia (2024) - Episode 14 (of 21): Together with Shoji

Tracker(s)

udp://tracker.opentrackr.org:1337/announce	S:	28	L:	9	C:	69	U:	125d, 3hr, 10min ago
http://anidex.moe:6969/announce	Scrape failed						U:	98d, 19hr ago
udp://tracker.torrent.eu.org:451/announce	S:	25	L:	8	C:	64	U:	125d, 3hr, 15min ago
udp://p4p.arenabg.com:1337/announce	Scrape failed						U:	4d, 11hr, 48min ago
http://tracker.anirena.com:80/announce	Scrape failed						U:	96d, 1hr, 31min ago
http://tracker.acgnx.se/announce	S:	1	L:	0	C:	152	U:	96d, 1hr, 25min ago
udp://tracker.tiny-vps.com:6969/announce	S:	9	L:	1	C:	485	U:	119d, 10hr, 29min ago
udp://open.stealth.si:80/announce	S:	22	L:	8	C:	54	U:	125d, 3hr, 15min ago
udp://tracker.dler.org:6969/announce	S:	0	L:	0	C:	0	U:	3d, 2hr, 26min ago
2 more trackers

File Name (Size)	[NeoLX] My Hero Academia (僕のヒーローアカデミア) - S07E14 (152) [1080p x264 10bits AAC][Multiple Subtitles].mkv (1.335 GB)
Download	BuzzHeavier \| GoFile \| MdiaLoad DailyUploads: Part1, Part2 KrakenFiles: Part1, Part2 MultiUp: Part1▼ BdUpload DownAce Fichier FileCloud Filerio FilesCdn IndiShare Kbagi Turbobit UpToBox Uppit , Part2▼ BdUpload DownAce Fichier FileCloud Filerio FilesCdn IndiShare Kbagi Turbobit UpToBox Uppit , Part3▼ BdUpload DownAce Fichier FileCloud Filerio FilesCdn IndiShare Kbagi Turbobit UpToBox Uppit
Screenshots	more »
Audio	GoFile \| MdiaLoad
Subtitles	All Attachments \| Arabic [ara, ASS], English [eng, ASS], French [fre, ASS], German [ger, ASS], Italian [ita, ASS], Portuguese (Brazil) [por, ASS], Russian [rus, ASS], Spanish [spa, ASS], Spanish (Latin America) [spa, ASS]

50 comment(s):

24/08/2024 14:38 * — ThisisLX

Thumbnail : https://i.slow.pics/VmTuM2Ig.png

(If it can give y'all an idea of the quality.. idk)

24/08/2024 15:12 — Anonymous

just make a regular comparison?

24/08/2024 15:35 * — ThisisLX

I wasn't trying to demonstrate my encode's quality is "better than" another one, just shared it to show the quality people can expect from downloading this video. They're big enough to make their own comparisons I think x)

24/08/2024 15:58 — Anonymous

the average user here doesn't know the difference between an mkv and mp4

24/08/2024 19:37 — ThisisLX

Even kids are able to appreciate pictures, I don't see why the average user couldn't?

24/08/2024 18:34 — Anonymous

It looks like what CR has, so I can get it a few hours earlier. Instead of waiting for a re-encode.

24/08/2024 19:36 * — ThisisLX

Don't forget to get your eyes checked every 2 years, it's important.

24/08/2024 22:41 — Anonymous

At least he isn't putting "High Quality" in every title like another releaser does. You are right in one aspect, the average user, most here watches on a laptop or other small screen device and usually delete after watching or after the season ends.

25/08/2024 02:11 — Anonymous

That another releaser is better at encoding than you though.

25/08/2024 02:32 — Anonymous

How would you know, have you ever grabbed any of my releases? You don't even know who I am.

25/08/2024 07:36 — Anonymous

I don't need to. I know eggxactly who you are.

25/08/2024 08:11 * — ThisisLX

If you think that anon is me, I'll call it right now : 🤡

If you think it's someone else that you think you recognized, then forget what I just said 😂

25/08/2024 08:27 — admin

Does winning an internet argument mean a lot to you?

25/08/2024 08:29 — ThisisLX

Not at all, it's just fun at this point lol
But you're right, it's pointless.. xD

25/08/2024 08:52 — admin

For clarity, my comment wasn't targeted at you.

25/08/2024 16:35 — Anonymous

You should definitely retarget towards him because if anyone is bent on winning an internet argument it's the gentleman above you. Replying with his username and also anonymously. If there is anything that reeks of desperation it is his behaviour.

25/08/2024 16:41 * — ThisisLX

So if we follow your vision, Japanimelvr that left a comment below without roasting me should be... me on another account? Right?

You're a clown.

25/08/2024 17:03 — Anonymous

>6min reply time

Touch grass, dude

26/08/2024 08:56 — Japanimelvr

Sorry I have no connection to ThisisLX or any other uploaders here. I am just a downloader and sometimes I make comments. Anyone can post under "Anonymous" and be the same person with a different comment. Before I came here I was on bakabt.me and was banned for leeching almost 7TB without uploading anything.
I don't encode...I download.

25/08/2024 13:16 — Anonymous

>I don't need to. I know eggxactly who you are.

Sure you do, lmao

Q 24/08/2024 21:42 — Anonymous

Why do you upload?
Do you need people to download your work so it would seem like you accomplished something?
If there are people downloading your work they should already know the quality of your uploads.
Why try to push it?

24/08/2024 22:08 * — ThisisLX

"Do you need people to download your work so it would seem like you accomplished something?" :
=> I upload to offer quality for an episode where the only releases are either CR/AMZN (not optimal quality at all), or minis (trash quality) and because I believe others are looking for quality encodes as well. The day someone will (upload quality encodes), I'll stop, no worries.

"If there are people downloading your work they should already know the quality of your uploads." :
=> Sure, but thumbnails of the actual encode can help people go out of their ways and try something new, so why not share one?

"Why try to push it" :
=> I only shared a thumbnail, relax?

25/08/2024 01:48 — Anonymous

Come for the Anime... stay for the drama.

25/08/2024 04:08 — ThisisLX

What drama? lol

25/08/2024 08:17 * — ThisisLX

I'll make something clear for everyone : I don't need anyone here to tell me that my encodes are great, that it's the best quality they ever seen or whatever, I know it's good (probably not the best, but far better than CR/AMZN and definitely minis) and most of y'all (apart from great encoders out there) have no legitimacy to criticize anything related to encoding.

I only wanted to share a little image so that people can get a grasp at how good it looks (I still find differences between the screenshots from AT and my encodes..). Now if people are still missing out on the opportunity to watch this good encode, I mean, it's their choice so I'm fine with that.

In any case, thank you to everyone who commented.
Traffic generates clicks, so hopefully some of the people that read these comments gave a chance to this encode ✨

Peace 🙏🏻

25/08/2024 08:50 * — admin

I still find differences between the screenshots from AT and my encodes

Are you willing to clarify?
Your last comment just pointed out a size difference, but didn't clarify any visible differences.

The screenshots here are supposed to be lossless and be an accurate representation of (one frame of) the video. If you believe otherwise, I'm interested in addressing it.

25/08/2024 09:13 * — ThisisLX

Nevermind that part, they're probably accurate enough now compared to how they were before.
It's just that I feel like I'm not watching the same thing sometimes (the screenshots from AT (vs) the video itself).
That's probably just me overthinking it tho.

25/08/2024 09:38 * — ThisisLX

Like here, if you zoom and focus on the people in the street (background and front) or the building on the right (that can be noticed without even zooming), you can see that your frame isn't accurate as there's some sliding or stretching (?) effect affecting these elements/colors : https://slow.pics/c/XrkAV8EA

On another one like this one, the scene is accurate (probably because it's a plain scene without too much depth) : https://slow.pics/c/IBPgXT3l

=> There are still size differences, the original frame being over 5MB and yours being 1-3MB, maybe your software or some server compression? Can't be called lossless..

These extractions were made using Vapoursynth, but still, that's minimal, it's just that I can tell by watching at the frame that it looks different... the average user probably wouldn't so... whatever ^^"

26/08/2024 04:24 * — admin

Thanks for the info!
Could you provide details on how you produced your screenshots, such that I can reproduce your result?

I suspect the difference is due to chroma upscaling. If that is the case, neither screenshot is more "accurate" as there's no "correct" way to do upscaling.

If you want to reproduce the image generated here, you can grab the original frame and render it via this ffmpeg command:

ffmpeg -i 001256e2_356360.mkv -vf "colorspace=iall=bt709:irange=tv:all=bt709:range=tv:fast=1" -pix_fmt rgb24 -sws_flags bicubic+accurate_rnd+full_chroma_int output.png

the original frame being over 5MB and yours being 1-3MB

I generally would expect 1080p screenshots to be around 2MB when saved as PNG.
Yours being around 6MB is suspicious if you do the math: 1920×1080×24bpp = 5.93MB
I suspect all your 1080p screenshots end up being almost exactly the same size, because whatever you're using to save PNGs is skipping Deflate compression. If you apply Deflate onto your PNGs (e.g. via GZip) you'll find the size goes down to what one would consider typical.
Check if your PNG writer has a 'compression level' setting - I suspect it's set to 0, which is why your PNGs are so large.

26/08/2024 08:01 * — ThisisLX

To generate the screenshots, I use this very basic code :

from vapoursynth import core
src = core.lsmas.LWLibavSource(r'video.mkv')
src.set_output()

Then "Preview" (F5) and right click, save, on the frame that interests me.

-----------------------------------

"I suspect all your 1080p screenshots end up being almost exactly the same size, because whatever you're using to save PNGs is skipping Deflate compression"
=> This is correct, at least for this episode, whether I use the source or encode, I end up with 5MB pngs.

-----------------------------------

"If that is the case, neither screenshot is more "accurate" as there's no "correct" way to do upscaling."
=> Looking at your code and mine, actually I do believe that mine is an actual (uncompressed) representation of my encode since you use -vf, -pix_fmt and -sws_flags commands which may affect the colors/overall look of the extracted frame, while my code simply extracts the frame without any added stuff (can't go wrong).

-----------------------------------

"If you apply Deflate onto your PNGs (e.g. via GZip) you'll find the size goes down to what one would consider typical."
=> Why would I want to apply further compression to a .png file that's supposed to reproduce the exact look of my encode?

After all, you're the one that said : "The screenshots here are supposed to be lossless and be an accurate representation of (one frame of) the video." Well if you want to go lossless, your method isn't the right way in my opinion :/

Anyways, hope this will help you correct the way screenshots are made on AT, so that they look more accurate to what the encode looks like (and so something good would come out of all this talk lol)

26/08/2024 09:49 — Anonymous

You're conflating compression with loss, but the discussion is around lossless formats being compressed. Quality is not lost with this kind of compression.

Think of it like audio where you can losslessly take DTS-HDMA or PCM and convert it to FLAC losslessly while compressing it and thus saving space. The output is still lossless yet it's been compressed.

Theoretically these 2MB compressed png's should have the same quality as the 5MB uncompressed png because of how the compression algo works.

26/08/2024 10:20 * — ThisisLX

"Theoretically these 2MB compressed png's should have the same quality as the 5MB uncompressed png because of how the compression algo works." + "Quality is not lost with this kind of compression."

As long as there are difference between an uncompressed version (VPY) and a compressed one (FFmpeg/Gzip), you can't call this lossless. A lossless frame would have absolutely no difference at all, and a "non-lossless-but-identical" one would have no noticeable differences either like in the comparison I shared.

Admin asked for clarification, I delivered.

If AT's screenshots are meant to be lossless, than VPY should be used instead of FFmpeg + Gzip, that's what I think, but it's Admin's decision, maybe it doesn't go with his automation process and FFmpeg is best for his use or Gzip is mandatory, idk.

I'd call these "accurate enough" at best anyways..

26/08/2024 12:17 * — admin

Thanks for the further details.

Then "Preview" (F5) and right click, save, on the frame that interests me.

What application are you using to do this Preview?
VapourSynth is a processing framework which doesn't provide any preview functionality (at least to my understanding).

while my code simply extracts the frame without any added stuff

That's not quite correct. Conversion is still occurring, you're just not being explicit about it.
You can test the ffmpeg command without the flags to see the differences if it helps you understand what's going on.

Why would I want to apply further compression to a .png file that's supposed to reproduce the exact look of my encode?

Deflate compression does not affect the look, it just reduces the file size without loss of data.
This isn't "you can't see it" (aka 'transparent') "lossless", it's 100% bit identical lossless.

Try zipping your PNG and notice the size difference. You can then unzip the file and it'll be 100% identical to the original file. This is what lossless compression refers to - size reduction with zero loss of data.

Responding to a later comment of yours:

If AT's screenshots are meant to be lossless, than VPY should be used instead of FFmpeg + Gzip, that's what I think

Note that VapourSynth doesn't actually do any decoding or rendering, it's just a processing framework.
In your script, your input is sourced via LWLibavSource, which tells you that libav is decoding your source.
The screenshots here don't use ffmpeg, they actually are decoded via libav as well. ffmpeg was suggested as a convenient way to replicate all the options used for rendering.

Unfortunately your script doesn't provide details of how the frame was rendered - this would depend on the preview application you're using.

26/08/2024 12:32 — ThisisLX

The rendering is through vsedit.exe which offers a way to preview the results of your scripts.

As for the rest, if you're able to explain the differences between your extraction and mine in another way than the compression or tool + additional settings used (ffmpeg for you), I'd be glad to hear it.

For now, I think I proved my point that these screenshots are not neither lossless nor accurate. They're close enough but differences still exist...

26/08/2024 15:08 — Anonymous

vsedit in 2024?

26/08/2024 16:16 — ThisisLX

As long as something works, it's usable.
I have no need for more at the moment, so yes.

27/08/2024 14:15 — admin

Ah so VapourSynth Editor is the missing piece of the puzzle, thanks.

Using its default settings, I can't actually get a bit exact replication of your output (though I did notice that it might vary the output bitdepth depending on your screen - if that has any effect), but it looks closer than screenshots I've previously tried to generate.
From VSEdit's code, it appears to be relying on VapourSynth's resize module to perform rendering. Not sure why it's different to libswscale - I'll investigate.

I think I proved my point that these screenshots are not neither lossless nor accurate

Unfortunately, you have proven neither. The only thing you've shown is that a difference exists.
You seem to believe that your output is perfect, but it's entirely possible that it isn't. Or perhaps both screenshots are accurate and lossless despite the difference.

09/09/2024 11:04 * — admin

Upon further investigation, VapourSynth's Resize module uses the zimg library for colour conversion instead of swscale (they even made a post about it). It seems like zimg is generally favoured over swscale, so it'd make sense to use that here as well.
Using ffmpeg's 'zscale' filter gives something closer than its default use of swscale, though I couldn't match VS' output, for whatever reason.

Since the PyAV toolchain I'm using doesn't have zimg support, I've started looking into using VapourSynth for rendering instead, over trying to hack zimg support into PyAV. When adopted, the screenshots here should end up being identical* to what ThisisLX produced, since the toolchain would be the same (save for version differences).
Thanks again for sticking with me on this investigation!

* but smaller, since the PNG will have Deflate compression applied.

24/09/2024 12:59 — admin

Screenshots are now rendered via a VapourSynth setup - they should be closer (if not identical) to what you see in VapourSynth Editor.

26/08/2024 15:09 — Anonymous

yes vs does not have any built in preview functionality, hence the use of vspreview by actually proficient encoders rather than vsedit (what neolx is using).

26/08/2024 16:10 * — ThisisLX

"By actually proficient encoders" : The preview tool you use changes nothing to the script's efficiency, that just proves you're dumb. I'll update the day that I'll need more than what VSedit can offer.

26/08/2024 16:21 — Anonymous

vsedit's dev was malding in the vs server because his shitware was no longer compatible.

27/08/2024 14:17 — admin

...and?

25/08/2024 19:22 — Anonymous

9 times out of 10, re-encoded CR is worse than CR and most of the so called great encoders share this sentiment. There's literally only 2-3 somewhat active encoders that actually improve upon things with their encodes and those usually end up being 3+GB an episode and on-par or better than the eventual lowpassed blurays. For everything else, CR WEB-DL tends to be better.

25/08/2024 19:34 * — ThisisLX

Really? So is mine "worse than CR"? If you think it is, would you mind showcasing why by sharing some comparisons and pointing out the "wrong"?
That'll give me something to work on, thank you!

25/08/2024 19:43 — Anonymous

I didn't say that. I've never compared your encode. I'm just saying in general, that encodes such as Chihiros for example are almost never better than simply using in-player deband on CR WEB-DL.

25/08/2024 19:49 * — ThisisLX

Oh okay x) well it really depends on what filtering the encoder does in the end, if it's just pretty basic stuff such as deband and that's it, then sure, you're better off just using the player's deband and save time.

25/08/2024 11:39 — Japanimelvr

It is nice to see someone sensitive about their work uploaded here but maybe you are a little too sensitive.
Most of the people that I know download an episode and keep it for about a week or two then delete it. I think you might be putting too much work into something that isn't going to be appreciated for long. If you like putting in the extra work to make something great that's fine... just ignore me. My 48 year old eyes can't really see a difference when I am reading subtitles and watching the episode at the same time.
These are just my opinions and I'm not an encoder or someone trying to start a fight or argument like other people.

25/08/2024 11:50 * — ThisisLX

The work I put into my encodes are for my own benefit as everything I encode ends up on an external storage drive for later rewatch. The extra step of sharing them takes me just a few minutes, so I don't mind, and some people are appreciating better quality (even tho they're very few, indeed).

So even if people watch and erase my encodes, or keep them for a few weeks and erase them, I'm good with that. What actually matters to me is that the option's out for people to choose it, if they want/need it.

Thanks for your kind comment, I'm glad some people are still able to discuss without looking to start a drama.. ^^

26/08/2024 11:30 — Anonymous

Damn, people do like wasting their time. (including me).

Add new comment

Name:

Comment Type:

Message:

Show formatting tags

<b>bold</b>	<i>italic</i>	<u>underline</u>	<s>~~strikethrough~~</s>
<code>`code`</code>	<sub>_subscript</sub>	<sup>^superscript</sup>	<spoiler>spoiler</spoiler>
<big>big</big>	<small>small</small>	<quote>quote</quote>	<a href="https://animetosho.org/">link</a>

Please be aware of the following before commenting:

Anime Tosho provides a mirror of torrents and is not the source. Please understand that uploaders/submitters may not read comments here, so you should check the Source Links section near the top of this page if you wish to contact them
Expired links do NOT get reuploaded as files are deleted after we process them
Uploads are NOT instant, so please wait for them to be processed. The entire uploading process is done by a bot which does NOT read any comments, so asking for links will have no effect on when they show up
Critical comments are welcome, however note that statements such as "X is crap" or "Y sucks" are NOT criticisms. Please provide reasoning with critical comments to be informative, helpful and allow for debate.
Personal attacks or insults are not welcome here. Such comments may be removed entirely and commenters may be temporarily banned.

Image Verification:

Our squiggly text game where the aim is to copy the image into the textbox. All characters are upper case, and there are no zeros (0) and ones (1) in the above image. Apparently bots aren't as good as humans at this game.