Yuru Yuri

Episodes – 12
Video – 1280×720, 1920×1080, crf 16
Audio – 2.0 FLAC (24 bit)
Subs – R1

Comparison TV/BD

720p – Torrent

1080p – Torrent

268 Responses to Yuru Yuri

  1. Petrushka writes:

    Hi10P….i’m ready!

  2. anon writes:

    @Alex:

    Have you tried making a codec by yourself? No? Shut up. You’re wrong. Reducing rounding error in intermediate steps can improve compressibility greatly. Oh, and motion compensation has everything to do with 10-bit; having a more accurate Fourier transform doesn’t help as much as not having large round-off errors accumulated from motion compensation. (Halfpel interpolation uses intermediate values with 6 more bits (i.e. 14 bits for 8-bit encoding, 16 for 10-bit encoding), which, guess what, need to be rounded off.)

  3. AlexTo writes:

    10 bit 0r 8 bit?, using an 8bit you can display 256 values of intensity level on RGB now 10bits would be 1024 intensity levels computationally 10bits is 3 times more true to the source, nevertheless, as human beings I don’t think my eyes can really differentiate 1024 level of intensity or even 256. Example if I have a RGB value of 200 – 0 – 0 in 8bits would be equal to 800 – 0 – 0 in 10bits.
    Now between R200 and R201 in 8 bits is the same as R800 – R804 in 10bit so in 10 bit you gain the ability to display 3 intensity levels more than in 8bit. I would really like to see a comparison between 8 and 10bit encode ans see if it’s really work it.
    regards

  4. Alex writes:

    >>> Have you tried making a codec by yourself? No? Shut up.
    One time. Unsuccesfully. But I’d learnt many from it. So go suit yourself, lad.

    I agree reducing rounding errors in MC can help compressibility _a bit_. At the cost of the scene quality, random noise will be introduced at FFT, poorly compressed losing some bits to the high frequencies, and then propagated as well. Only special psychovisual filter profile may help there (highpass at 8 bit level), but don’t really know if it will.

    And more. If we have less quality at the FFT step, no motion compensation can regain that, because all the defects here will be propagated.

    >>> Halfpel interpolation uses intermediate values with 6 more bits (i.e. 14 bits for 8-bit encoding
    And there it is. Why do we need another questionable method to do that?

    >>> using an 8bit you can display 256 values of intensity level on RGB now 10bits would be 1024 intensity levels
    Also, the source is 8-bit. We won’t magically get 2 extra bits of quality from nowhere.

    The point is:
    PROs:
    Questionable increase of compressibility.

    CONs:
    Much more CPU resources needed.
    No H/W acceleration possible.
    Unplayable on most players.
    Unplayable on hardware players.
    Questionable loss of quality.

    • coalgirl writes:

      PROs:
      Questionable increase of compressibility.
      >It is a proven fact that compressibility increases with use of 10-bit. It’s not questionable.

      CONs:
      Much more CPU resources needed.
      >So? Don’t play it at all if you care so much about CPU. Go stream it on youtube. That takes 0 CPU. If you have it, use it.
      No H/W acceleration possible.
      >Buy a better computer if you have trouble playing 720p.
      Unplayable on most players.
      >It plays on MPC supported by CCCP, which is the only thing we support.
      Unplayable on hardware players.
      >See above
      Questionable loss of quality.
      >No. In every test I’ve done using the same crf the result is higher quality for less bitrate.

      If you want to whine about how you hate 10-bit, a BD encoding site is not the place. Go find somewhere else.

  5. LoverOfPizza writes:

    I have a 5 GHz CPU so I am ready for this.

  6. anon writes:

    I got a 400€ Laptop – and it uses 34 % of _one_ core. Don’t know what all the people are bitching about. Your PIII is ok, but if you want to watch videos you have to spend at about 150€ for a new cpu+motherboard and it’s worth it. Trust me.

  7. nINJAkECIL writes:

    I downloaded the mid-batch torrent, and check them out with the episodes I already downloaded, and there’s one file (ep.4) which is different. Would you mind provide us with patch? I red the critique @whiner.pro, and it seems like it’s only typesetting issues, and not encoded issues.

    As for Hi10P, why don’t you gives this a [Hi10P] tag, just to make sure that we know we are downloading 10-bit encoded video?

    Btw, playing nice and smooth here with ancient Intel Pentium E5200, 4GB RAM, nVIDIA GT240.

  8. coalgirl writes:

    1. Group policy is no patches
    2. I believe that 10-bit is simply an encoding setting, similar to mb-tree or weight-p. So I do not believe that something like that needs to be labeled.

  9. Alex writes:

    >>> If you want to whine about how you hate 10-bit, a BD encoding site is not the place. Go find somewhere else.
    Okay, I just won’t do that anymore. Sorry for that.

    Don’t want to offend, but the Yuru Yuri has some problems. Don’t know if this is source or encode, but chroma noise is terrible as seen on the IPS 24″ LCD. May you please confirm, if this is source problem or encode problem related to the smaller file size?

  10. fulun writes:

    Great, now we know he has an IPS monitor, but it seems he doesn’t know IPS panels aren’t made for watching anime, or better to say, watching anything that “moves”. Are you sure that’s not your monitor falling behind because of its 8-16 ms delay? 🙂

  11. inko writes:

    Alex: Poor broadcast quality, as addressed earlier. Or something on your end like sharp chroma sampling, poor colorspace conversion, or display drivers.

    fulun: Get/open calculator, divide 1000 (milliseconds in a second) by 23.976 (frames per second).

  12. Anon writes:

    thanks babe

  13. Velichi writes:

    Does he mean the noise typical of scenes such as E1 10:12 – 10:35 (Mirakurun transformation scene heavy detail)? That part (and the recurring scene elsewhere else in the series) is (a tiny bit) noisy. It’s not a problem otherwise.

  14. fqe writes:

    new banner, loving it

  15. Crimson writes:

    Everything is fine with MPC-HC 1.5.3.3666 and ffdshow 3970 on Intel Core Duo 1.666Mhz with nVidia Go 7400 (no DXVA) with up to 25% CPU load. And only 100mb per episode in 720p? Awesome! Love 10bit. And only if you were to reconsider wasting bitrate on FLAC… Will you reencode previously released BD rips? I think lots of people would like to see changes in quality and filesize. I’m sure I would.

    • coalgirl writes:

      Right now, there is only 1 show I have done that I believe the value gained in a re-encode exceeds the cost to me to go through efforts. This show was not one of our particularly popular ones, however, so I wouldn’t hold your breath.

  16. Kenshin writes:

    I don’t know where else to post this, but I was wondering if you were planning to get your hand on the Ruroni Kenshin: Tsuiokuhen(Trust and Betrayal) LE blu ray that comes out next week and release it on the site?

    I am not going to badger or beg you if you do not, but I enjoy the quality of your releases and do apologize once again for not know where to inquire about this kind of thing.

  17. petrushka writes:

    the new banner is full of WIN! I love it!

  18. mtwini09 writes:

    Im still undecided about this Hi10 thing. I seriously cant see any difference in quality between this and the 8 bit stuff. Then again I cant really tell the difference between most mini hd files and the originals unless its bluray. For my own opinion, its not really necessary because there is that mini hd stuff and bluray releases dont have to be small file sizes anyway. Good to experiment though 😀

  19. incko writes:

    I love the new banner of your website
    keep up the good work!

  20. Anonymous writes:

    dat banner.

  21. anon writes:

    Might you gentlemen and/or ladies be so kind as to provide a link to the original image of that awesome new banner? Or was that simply taken from a screenshot of the show? It would be much appreciated, I plan on making it my wallpaper, but I’d like to get it at a higher resolution.

  22. John writes:

    Cardcaptor Sakura in 10bit!?!? 😀
    So you can do a whole new batch with the new BD movies 😀

  23. nobody writes:

    lol this is too great. i was just thinking how awesome it would be if coalgirl released this a day early, i check the website and BAM

  24. cerby writes:

    meh, moaaar.

  25. Frisz writes:

    hey can you all help me? me try to open fileserve.com and megaupload.com but it seems error
    I don’t know why it become like that and when I asked my friends to open it on other computer at their home, they say also say error. What’s happening?

  26. Martin writes:

    Can’t play it on my netbook and my TV doesn’t like it too. I prefer normal 8-bit releases.

  27. Yngwie writes:

    Thanks CG; plays beautifully with mplayer2 and libav.

  28. kevin writes:

    Hey guys, thanks for subbing this show it works great on my ps3 though ps3ms. But for some reason i am having trouble getting it to work on my computer with mpc using the 7-30-11 cccp. I cannot play any of the 8 yuru yuri episodes. When i open the file, i get a blank black screen in mpc with no audio. if i move the seek bar, it will be moved there but nothing happens.

    Anyway to fixed this?

  29. NobleScarlet writes:

    Finally got it to work with Zoom Player 7 Max. Just install the ffdshow and Haali’s Media Splitter from the CCCP installer after running the Install Center from Zoom Player, and it’s good to go! Weeee!!! ^^

    Won’t work on Zoom Player 8 RC2 though…

  30. plague1ftw writes:

    3. My type of show = cute girls doing cute things. Don’t think you know me more than I know myself.

    haha just saw that, sorry I won’t doubt your love for cute girls doing cute things again 😛

  31. Randy writes:

    Stupid question but these are from the tv right, not blu rays?

  32. PrivateVar writes:

    PROS:
    1. FILE SIZE: For slow speeds and/or those with little storage.

    CONS:
    1a. NO GPU SUPPORT: All new-ish GPUs flawless TrueHD 8-bit h264 decoding capabilities. With a modern OS and software – GUIs, Browsers, Games and Video fully utilize the GPU – CPU is not meant for these areas.
    1b. NO CUDA: This should be obvious. Both CoreAVC and LAV CUVID simply access GPUs video decoding chip using CUDA – that chip has no support for Hi10P.
    2. SOURCE IS 8-BIT: Hi10P offers more detail, but there is no extra detail availabe from source.
    3. NETBOOKS: Many people use them. Newer and powerful have GPU h264 decoding, being able to play back HD content (screen resolution can be more than 720 or be hooked up to HD monitor). But for Hi10P h264 can stutter and lagg horribly.
    4. PAD DEVICES: Popular and like netbooks – high performance w. 8-bit (GPU) – possibly no support at all, or horrid performance, with Hi10P.
    5. QUALITY: Most notebook / netbook monitors skew colors. Most people do not sit close enough to their monitor to notice. 10bit Quality Advantage = Gold Plated Audio Jacks.
    6. THERE WILL BE NO GPU SUPPORT: Who is the primary consumer of 10-bit H264? Pirates.
    7. CONSOLES: Statistically these are preffered media centers. HALF of Netflix users use them, obviously pirate statistics are harder to come by.

    PLEASE VERIFY THAT YOU,

    1. Do not care about supporting Game Consoles, their media capabilities, and their user base.*
    2. Do not care about supporting GPUs media playback capabilites, and those who rely on GPU power for smooth SD/HD playback.
    3. Do not care about supporting netbooks and their vast user base.
    4. Do not care about supporting iPads, various similar devices, and their vast user base.*
    5. Do not care about the ever increasing storage capacity ever diminishing needs for small files.
    6. Do not care about the ever increasing internet transfer speeds ever diminishing needs for small files.
    * to a minimum degree of encoding to 8-bit h264 (ignoring media container support and audio support) or better

    • ChrisK writes:

      HD anime should be watched on a decent computer hooked up to a flat screen TV or decent sized computer display. This scenario and creating state-of-the-art encodes are the only things we care about.

      If you want files playable on your plastic toys, go load a Xvid Re-Re-Reencode.

    • coalgirl writes:

      Let me fix a few things that are wrong.

      1. Pro’s are that it increases quality WHILE reducing filesize. 10-bit severely reduces banding and problems related to it.
      2. 8-bit to 10-bit to 8-bit has been shown to produces higher quality images than 8-bit to 8-bit to 8-bit. Being 8-bit in the first place has nothing to do with the end result. Video are also MPEG-2 at the start for TV, but it’s better to use MPEG-4 in the end.
      3. Banding is not placebo.

      Now here’s what I will verify.
      1. I don’t care about any of your toys. Watch it on a PC, or via a HDMI hookup.
      2. If you rely on GPU, get a better computer. I play back 720p 10-bit flawlessly on a 2.3 GHz dual core laptop.
      3. You’re seriously DLing from a BD encode group to watch on an 8″ screen of a netbook?
      4. iPad’s are like iPhones last I saw and require retarded settings like baseline profile to encode. For 3 and 4, if you want that, you’ll need a specialized re-encode group, not us.
      5. >Implying I do anything for the sake of filesize a few weeks before I release a 30 GB Macross F batch
      6. See 5.

      The problem is that you’re expecting these releases to be for every userbase. Nobody does that, 8-bit or not.

  33. Tim writes:

    2. I believe that 10-bit is simply an encoding setting, similar to mb-tree or weight-p. So I do not believe that something like that needs to be labeled.

    The difference is that with mb-tree and weight-p, it was possible to support hardware offloading for playback via driver updates and software changes. This appears not to be the case for Hi10 – they will require new hardware to play back if you don’t currently have a powerful enough CPU (and currently no hardware on the market has support).

    Labelling so that people are aware of this seems to me to be a sensible idea.

  34. Astara writes:

    CONS:
    1a. NO GPU SUPPORT: All new-ish GPUs flawless TrueHD 8-bit h264 decoding capabilities. With a modern OS and software – GUIs, Browsers, Games and Video fully utilize the GPU – CPU is not meant for these areas.
    1b. NO CUDA: This should be obvious. Both CoreAVC and LAV CUVID simply access GPUs video decoding chip using CUDA – that chip has no support for Hi10P.
    6. THERE WILL BE NO GPU SUPPORT: Who is the primary consumer of 10-bit H264? Pirates.

    1) Cuda is a programming language, not a chipset. It allows you to program shaders to
    do tons of scientific physics and parallel tasks — that it couldn’t be programmed to decode Hi10 seems unlikely… case in point:

    2) See http://haruhichan.com/wpblog/?p=205 — especially ‘madVR’ decoder which uses
    graphics hardware to decode 10-bit
    3) http://www.digital-digest.com/software/madVR.html — under change log:
    ‘fixed: internal decoder showed 10bit video with non-mod-4 width distorted ‘.
    (i.e. it’s been working — just not for widths that didn’t divide by 4)…
    Another note:
    # bypasses graphics card’s video (damage) algorithms
    # all work is done via GPU shaders
    —-
    Exactly what CUDA is for — letting you access and program the shaders to do ‘whatever’…

    4) CoreAVC 3.0 currently in beta and set to come out in the next couple of weeks and the main feature of the release is 10bit. Source: doom9.org
    Not sure if it will include CUDA support, but most people that use CoreAVC, usually use it for CUDA. Otherwise, FFDShow works just as well.

    Also saw someone making inquiries about ‘atom’ support for HI10 in another forum, and the answer people thought was ‘soon’, as Intel wants to support Japan as a primary customer and many vids are coming out in 10-bit format now…

    So, before you get all upset and have a heart attack, you might wanna check the sources of your information, cuz it seems like HW support is already available (for free — madVR = free), and other options sound like they will soon be available.

    Astara..

  35. bzlai writes:

    is it just me or am i downloading a 101mb file called yuri with no extension from the expisode 10 torrent?

  36. tormaid writes:

    @Astara
    Yeah, MadVR is going to be MORE hardware intensive.

    “Guess we finally broke the 1 GB mark for the series.”
    10-Bit <3

  37. Astara writes:

    ChrisK — ahhh… good to know.

    Fortunate for me CoreAVC just released 3.0, and it handles Hi10 just find…

  38. Astara writes:

    Oh, FWIW, Hi10 uses about 2-4Xthe CUDA % in decoding (albeit, correctly, though) the Hi10 format…i.e used 3-6% before, uses about 12% GPU now. CPU dropped from around 8%(48%/ 1-core) to about 6%(36%/1)…

  39. ulz writes:

    More like “cute things doing cute girls”.

  40. Icaro writes:

    “I play back 720p 10-bit flawlessly on a 2.3 GHz dual core laptop.”

    `Phew. I’m so relieved after reading this. I thought 10-bit required like a 5GHz CPU or something. With all this talk of “10-bit requires moar engine power” I was worried I couldn’t watch these releases.

  41. horus writes:

    Just to throw the wolf in with the kittens here, my little Dell D620 (1.83 GHz CoreDuo) is running Hi10P just fine using Xine, VLC, and MPlayer (except that MPlayer misinterprets the subtitles). That’s with an Intel integrated video card (GMA945?) and full-screen (1280 X 800).

    No huge hardware here, but I do have a 7200 RPM drive in this thingy – I’m sure that helps.

    OS? Why, PCLinuxOS 2011.06 KDE-4.

    I’m enjoyng Yuri Yuri very much. Thank You, Coalgirl!

  42. GenesisAria writes:

    Hmm…
    I’ve been Googling and poking around, yet I can’t get anything for 10bit.
    What are you using for encoding 10bit video? (I tried MediaCoder but it just tells me the encoder is absent)
    I would like to re-encode some of my own stuff to free up space.

    I have no issues with playback; (had to manually insert it to MPC as external filter tho <= i don't like CCCP) I was quite surprised at the amazingness of this when i got it working.

  43. horus writes:

    Ack! Just noticed this morning that the title is YurU Yuri, not YurI Yuri as I had previously stated. Anyhow, enjoying it much. Are there two more episodes of this coming, or is the 12 count including the OP & ED? Just askin’…

    I’m noting (in closer review) some tearing and blocking (just a little) and a brightness/contrast washout issue for the first few seconds of playback using Xine, but it straightens up nicely after that. I have a feeling I’ll find a parameter I need to set to correct for this, though, after I’m through digging.

    Thanks again for doing these. They are providing some enjoyable test video for Hi10p compatibility tests. It’s hard to keep good test logs when I’m laughing this much, though.

  44. dingle writes:

    Did anyone even bother to test the effects of 10p upsampling compared to other rounding methods that don’t require on the fly downsampling overhead?

    The fact that rounding/blending of information helps compressibility is nothing new, so it’s confusing to see this pushed with no comparison to methods that don’t require on-the-fly processing (like deblocking filters). It’s also confusing to see this being pushed as better quality when it’s clearly less accurate to source, though I guess this creates the perception of better quality if the source has banding issues.

  45. David writes:

    I’ve been poking around the last few days, but can’t find anywhere that really talks about this.

    My question is, what metrics do you use to determine the ‘quality’ of the output? And by extension, what quality metric do you aim for to determine what settings to use for your encode?

    SSIM (literal, inverse or decibals)? PSNR? Bitrate? Subjective viewing? If subjective, do you do side-by-side comparisons with the original, and if so how are comparisons evaluated? Other?

    I realize CRF encoding is desirable as an “encode at this quality” parameter, yet a given CRF can produce vastly different values in the other metrics depending on source and settings, so it’s not very useful as a target metric (and in many cases is explicitly not useful).

    For the highest quality encodes, what method do you use to determine transparency with the original? How does this measure vary with video resolution?

    When you consider measures such as “doubling the quality” (eg: going from 0.98 to 0.99 SSIM), it’s really more like halving the number of errors. In the Hi10P analysis of the value of the number of bits used, going from 8 to 10 bits reduced roundoff errors by 75% (~4x quality), but doubling again (going to 11 bit, and then another double to 12 bit) did almost nothing to improve subjective quality. There just weren’t enough errors left by that point that halving them again made any noticeable difference.

    And, given all that, what do you see changing in your target metrics as you transition to Hi10P?

  46. Kal writes:

    I tried it, and it works just fine. File a lot smaller, and it looks just the same as any other. I’m using the latest k-lite codec pack.

    Also, I tried it with the PMS (PS3 media server), and I was able to stream that file just fine to my PS3. So looks good, is smaller, and I can stream it just fine. Count me in!!

  47. machalita writes:

    Geez people, i dont have any playback problems with the latest K-lite pack. If they didnt say anything about the video being 10bit, i wouldnt notice. Just upgrade your software and codecs, dont expect newer stuff to work with 3 year old software/hardware.

    This is just like when people where complaining bout how windows vista sucked on a pentium 2.

    Thanks for the great job and releases =)

  48. gazsipiszi writes:

    I totally agree with coalgirl, that it’s his/her choice how he/she encodes, but I also agree with nINJAkECIL that there should be some kind of indication of it being Hi10p, because many of us DO use those “plastic toys” (like netbooks and nmt-s), not because they are powerful, but because of their power consumption (and ease of use) while doing effectively the same thing as my (now) midrange 4-core PC.
    My PC uses >150W just to be on, while my popcornhour uses less then 20W to play a 1080p h264 movie.

    Then again, it’s no big deal if I know that i can’t play it on anything but my pc or laptop. It’d just make life easier to know this beforehand even when only browsing T.T..info.

    ps: I like these 10bit encodes and coalgirls 🙂 (but my wallet certainly won’t XD)

  49. ZeRO writes:

    >gazsipiszi: I totally agree with coalgirl, that it’s his/her choice how he/she encodes, but I also agree with nINJAkECIL that there should be some kind of indication of it being Hi10p

    there is no point doing that. besides not supporting hi10p, standalone players and the likes have various other limitations like not supporting high@5.1 features, anything higher than an arbitrary peak or average bitrate, reframes, lack of header compression and ordered chapters for mkv containers…etc..
    While it might be nice to have a MediaInfo summary alongside a release tagging it with that stuff would be insane.

    As for device compatibility, hi10p is hardly anything new, players not too old or too cheap (by means of support/firmware updates) will probably soon get updates (and new devices will support it) as hi10p gets increasingly popular. if we were to wait for existing low end hardware to catch up as technology progresses, we would still be spinnign vcds today.

    Also, it’s interesting that file size now doesn’t seem to matter anymore after all the nagging about “huge” files this group probably had to endure in the past.

    Also, thanks a lot for this release!

  50. gazsipiszi writes:

    @ZeRo:
    If we look at it like that, then what’s the point of writing [h264] and [AAC/FLAC/…]? a computer can play everything so you don’t really need these info’s either xD

    on the side note: the only 2 media I came across not playing on my player (aside from hi10p) was the >50Mbps Killa sample and the D*k1-Ch1h1r0 Motto To Love Ru 1080p BD rip. (and the ToLoveRu doesn’t play in DXVA either). A 40Mbps sample @ H5.1 played fine, along with Transf.2 20Mbps/H5.1