Naruto 80 Filesize

[StealthShinobi]

I'm confused as to which is the accurate filesize of naruto episode 80. most seem to be 148.67MB but i've also seen quite a few 116.75MB ones. Please post if you have seen this same thing or know a way to settle this. One-sided opinions dont really help, because it could just be that you've only seen one. Somebody please find a way to settle this. Could it just be that they realeased a vetter quality one? Please help answer this...

Thank You

[MemnochTheCaT]

Originally posted by: StealthShinobi
I'm confused as to which is the accurate filesize of naruto episode 80. most seem to be 148.67MB but i've also seen quite a few 116.75MB ones. Please post if you have seen this same thing or know a way to settle this. One-sided opinions dont really help, because it could just be that you've only seen one. Somebody please find a way to settle this. Could it just be that they realeased a vetter quality one? Please help answer this...

Thank You

The proper A/A one is the 148mb one i/expressions/face-icon-small-smile.gif

[StealthShinobi]

are you absolutlely certain? why is it so small this week?

[kage_bunshin]

its definitely the 148mb one

Some how ANBU-AonE managed to compress it so much!!
the video quality is the same as the 170 to 180mb ones!

[MemnochTheCaT]

From my personal experience with encoding, it is small because there are a lot of static frames in this episode, which are much easier to compress because of repeating/reduntant data. The way DivX/Xvid and similarly, Mp3 works, is by eliminating or abbreviating information that can be cut out and 'filled' in, without the end product being affected.

A very simple way (and not at all comprehensive) of looking at is like this. Say that you wanted to send this text information in the smallest way :

ARYTRAVVVVVVVVVVVVVVVVVVVVVVVVIYOP

You could abbreviate that by sending 'ARYTRAV(25)IYOP .. and have the reading program interpret the (25) code to fill the missing data back in, in this case the letter V.

Alternatively, the encoders could have changed some settings, but the quality is still excellent, so my guess is that the content of the episode (lots of still scenes) .. was especially friendly to high compression!

[kage_bunshin]

Wow MemnochTheCaT,you seem to know your stuff!

[Cal_kashi]

I know that mpegs work this way, and i believe that divx does too, is that frome frame to frame, only things that have changed are refreshed. For instance If you have a video of a windless grassy field with a squirell hopping across it only the pixels pertaining to the squirell are refreshed, the grassy field and the sky reuse the same pixels as the previous frame, saving space. However, if suddenly a wind picks up all the grass pixels have to refresh whenever they move (taking up more space) but the sky keeps using the same unrefreshed pixels as from the beginning. This answer is similar to Memnoch's but goes into slightly more detail. This also explains why things occassionally get choppy when there is ALOT of movement, it stresses the cpu much more to be refreshing teh entire screen as oppossed to very little of it.