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)

Please fetched this

Nandesukaka officially quit. Again. Don't expect them to seed anything anymore. Not that they ever had any retention.

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

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.

wrong subtitle.

Buddy you're in no position to complain about grammar lol

I wish just the subs from this could be put up here

It's fairly easy to change the subs to your liking.

>There's a couple of bad grammar in this episode

Oh the irony...

There's a couple of bad grammar in this episode, it's a shame because the previous episode didn't have the bad grammar as far as I'm aware.

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.

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.

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!

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.

>6min reply time

Touch grass, dude

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.

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.

Could someone please seed this file?