A cute little short.  Thanks.  Reminds of classic burlesque.
( English subs in video - don't show in thumbnails, but does in screenshot 3)

Thank you for fetching this.

use the attachments provided by Memories below.

While all v1 episodes were fetched previously, all 12 episodes got a v2 (and no patches were provided). And the batch also includes the openings/endings.

Attachments: https://files.catbox.moe/r8agn2.7z

...and?

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.

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.

Doubtful, all the eps in this batch have been fetched already.

Hello. Can this be fetched?

0 seeds it's stuck at 66%

This torrent is still being processed ?

The videos has both Chinese and English subtitles blend in.

The videos have both Chinese and English subtitles blend in.

GoFile isn't the only ddl that AT use, tho.

Yeah, every other ddl here is crap.  It would be time to (groan) move on to torrents and vpns.  I guess I'd want a torrent client that runs inside my browser so my ISP doesn't see it, a so called 'web-torrent' client.

Animetosho was alive before you were born.

Say what? AT does not depend on GoFile to survive. Over the years file hosts have come and gone yet AT is still here.

if gofiles cuts  AT, then AT is done.

At the time the OP posted this wasn't fetched due to the size.

follow series link to other listings, and download subs from them? Timing often matches.

episode 389... missing footage.

they are. all attachments

"Dorami-chan-_Hello_Kyouryuu_Kids!!_-_1_-_Complete_Movie_-_(d11f363d)(RAW).wmv"
still has 1 seed, lacks subs
download subs from
"[Inka-Subs] Dorami-chan - Hello Kyouryuu Kids!! (Hello Dinosaur Kids!) (1993) 1080p".

"There's a sucker born every minute."

Tari tari is Yuri anime, togetoge is shounen manga.

Hello,
is TariTari related to TogeToge?

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

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

"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.

This is episode S01E08, as evinced by the filename, and Nyaa's own title was updated. The actual S01E07 was posted after this one.

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).

vsedit in 2024?

and the other episodes? 7,8,9,10,11,12?

8 episodes ? not more?

thank you very much

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

Thanks for the further details.

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).

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.

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:

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.

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

"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..

Can this be fetched, please?

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.

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.

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)