i was simply throwing a little new york sarcasm around, I'm satisfied with my puny time warner cable :o or maybe i'll move to sweden and bask in 100 women/mbits.
Printable View
i was simply throwing a little new york sarcasm around, I'm satisfied with my puny time warner cable :o or maybe i'll move to sweden and bask in 100 women/mbits.
I don't think the sceners would want to sacrifice their own security (FTP uses SSL, while Bittorrent only offers PE) for their file's integrity (Bittorrent checks for errors, while FTP doesn't).Quote:
Originally Posted by Wildclaw
i prefer my files in rar's.
rar's should be ok , less size more content
But the scene's rar'd files are merely stored for the sake of integrity. They aren't compressed to any substantial degree.Quote:
Originally Posted by bladesharp
Rars aren't ok. For the sceners, raring is useful, because it ensures file integrity, which is precisely what FTP lacks, however necessary the protocol is for security reasons.
For the torrenters, however, rar'd releases are cumbersome. There are programs that allow you to read archived files without extracting them, but we just shouldn't be expected to do that, when the alternative (unraring before uploading...) is so much simpler.
i agree with you 100%Quote:
Originally Posted by AcumenBut the scene's rar'd files are merely stored for the sake of integrity. They aren't compressed to any substantial degree.Quote:
Originally Posted by bladesharp
Rars aren't ok. For the sceners, raring is useful, because it ensures file integrity, which is precisely what FTP lacks, however necessary the protocol is for security reasons.
For the torrenters, however, rar'd releases are cumbersome. There are programs that allow you to read archived files without extracting them, but we just shouldn't be expected to do that, when the alternative (unraring before uploading...) is so much simpler.
you are right. some people don't read threads or try to understand answers before they reply, so don't bother.Quote:
Originally Posted by AcumenBut the scene's rar'd files are merely stored for the sake of integrity. They aren't compressed to any substantial degree.Quote:
Originally Posted by bladesharp
Rars aren't ok. For the sceners, raring is useful, because it ensures file integrity, which is precisely what FTP lacks, however necessary the protocol is for security reasons.
For the torrenters, however, rar'd releases are cumbersome. There are programs that allow you to read archived files without extracting them, but we just shouldn't be expected to do that, when the alternative (unraring before uploading...) is so much simpler.
the players that play rar files are terrible and of course they unrar them as well. you just don't notice this step. they hardy have the ability to skip or shuttle. it's not worth it in my opinion.
rars give uploaders or trackers that extra second or minute (depending on the size) of pretime.
for those who didn't get it: they are not necessary nor do they have any advantage for bittorrent in general.
uploaders or even upload bots upload a lot and they want to do it fast. the only argument for rars is that they (uploaders) do the important job and one should allow them a certain laziness hence not to do the unraring for us. although i would accept the worse pretime with the benefit of saving 100% hd space when i watch the movie.
i prefer unrared. there isn't one really plausibel argument for rars on a bittorrent tracker. bitmetv or theconnection for instance made the right decision.
p.s. i like it that there are newcomers in this thread who understand bittorrent and make useful, informative posts. :)
some other n00bs should take this as an example.
simple then isnt it,
If you hate rars, dont use trackers that force rars, use trackers that have no rars, and unrar scene releases before uploading.
Bittorrent error checking is NOT 100% fool proof. Just because you have never seen it happen, does not mean it does not happen.
Like i said previously, i will not touch a torrent that is not multi rared, i have seen far to many go tits up in my time, but each to their own i suppose.
this is like the 100th time this subject has been debated here at FST..
please search the forums before postingggggggg! ahh
almost as bad as the favicon threads!
I prefer unrared also. I do not mind using trackers that use rar files though. I'm used to it now. Plus, when getting a rar'd file, I can re-seed it to either a place that requires rar, or a place that doesn't. Only having the un-rar'd file, you can't re-seed it (or I haven't figured it out anyway).
Either way, computers are fast enough that I dont mind waiting a few to watch/play/listen to something. I usually either move the extracted copy to my xbox or burn whatever it is, then delete the unrar'd copy.
both have their advantages and disadvantages tho i personally prefer unrared .
the only problem is that incase the file gets corrupted u gotta download the whole thing again which would be a pain . this is where rar files really help .
but one thing i cant understand that why the scene still opts for rar and zip small apps ? way too much unnecessary compressions used for small apps of 5-10 mb softwares . its basically just the .exe file , crack/keygen file and the .nfo but still both rar and zip compressions used for them .
I have to agree with that one, i hate the way they do that with apps, and i think that way we can do without.
I used to extract every single one indibidually and it was a right pain, now though i just selct the lot and unrar here and it works a treat lol
I don't know if they are 'scene' apps or not, but I HATE the multi rar each inside its own rar, all inside yet another rar. WTF is up with that crap?!? I've seen it more and more lately...
Yup, I know. That last part was kind of half joking.Quote:
Originally Posted by Acumen
It is too bad that ftp (and http) doesn't have any strong error detection built into them. The error detection in tcp and underlying layers is simply too weak and prone to error when dealing with large amounts of data transfer. Even allowing a single error to slip by is too much.
my personal preference is unrared. IMHO bittorrent don't need rared stuff... its just a waste of electricity.
This isn't some weak 32bit crc32 checksum we are talking about. It is a strong 160bit (1.46×10^48 combinations) sha checksum. If your bittorrent client has checked the file(s) and says that it is correct, it means that it is a byte for byte replica of the file(s) that the torrent file was created on.Quote:
Originally Posted by stoi
If you have completed a bittorrent download with an incorrect file, there are two reasons, neither which you can blaim on the bittorrent protocol.
First, Your bittorrent client didn't actually check the files to see that they are correct. This is easily detected by right clicking a torrent and selecting force recheck. If the completed percentage changes from 100% to something else, that is what happened. As bittorrent clients automatically checks anything downloaded, the reason for this happening is most likly a combination of a bad hard drive (buy a new one quickly before the old one crashes completly) and having turned off double checking after download is completed (which is an automatic forced recheck).
More likely however, you did the above and it is still at 100%. In that case there is only one explanation. The incorrect file was already incorrect when the torrent file was created. The creator should have made sure that the file was correct before creating the torrent file.
Ok, I admit, I am ignoring the possibility that you won the national lottery several times in a row, and fate now wants to even things out.
so how come i seen it happen not 2 weeks ago like i have said 3 times in this god for saken post now.
Uploader rared a torrent. he tested it, he extracted it, he made the torrent, he hash checked it, it got to 100%, he uploaded it. members snatched it, so got to 100% and were seeding.
They went to unrar it, and it wouldnt unrar for any of them, never mind 1 or 2.
so he unrared it again and it unrared fine.
so it cant be that good (and this isnt just a 1 off either, its happened to me personally on more than 5 occasions over the past 4 years), and we must see this on our tracker at least 20 times a year.
a small paste from: The iso rules agreed upon by CIFE, RiSCiSO, and RAZOR ISO.
7. All RAR's will be listed as ".001 -> .0xx" as opposed to ".RAR ->
.RXX", for the directory listing's sake. RAR is the official standard.
Section III: Archive Creation
The fastest and most efficient archive program is RAR. Once you have used
CDRwin to create your .bin and .cue files, or EZ-CD Pro to create an .iso
file (*** see note above), then you want to use RAR or WinRAR to break up
the image file into workable pieces that can easily be spread on the
Internet. If you try and upload a 700 meg single file to an FTP site,
you're going to have trouble. If your connection dies in the middle of
the connection, you're screwed. Some FTP programs have resume features,
but it usually doesn't work, therefore we advocate using RAR. You can find
shareware versions of RAR and WinRAR by searching the web, it is available
everywhere.
Here are the rules for using RAR:
-- If possible, use the maximum available compression. However, if you
are racing a release, or you simply don't have the time to wait for
maximum compression, then use default to light compression. This all
depends on how much time you have available to sit around. Higher
compression will save a LOT of hard drive space, but it can take a very
LONG time, even on a fast Pentium-II processor with 64 megs of ram.
-- Use 15 megabyte segment splits. Thus, you want to break that 700 meg
.bin file into smaller pieces, each of size 15 megabytes.
-- Turn *OFF* solid archive mode. In both WinRAR and DOS RAR, solid
archive mode is defaulted on. You must go into preferences and turn it
off. For DOS RAR you must turn solid mode off as well by using the menu
options or command-line options. In either case, be sure that you are not
creating a solid archive, because if you do, the FTP sites will not be
able to test the CRC integrity of each of the individual 15 meg segment
file.
-- Include the .bin, .cue, (or .iso) and "risciso.nfo" inside the RAR
archive. Be sure that you have filled out the risciso.nfo file to include
all of the details of the release, including how many CD-ROM discs it is,
a general description of the program, any necessary OEM or serial numbers,
and any other details you like (keyboard shortcuts, game hints, web site
to see screen-shots, etc).
the way it is and the way it always will be.
I like them unrared but then again I don`t really care about who they are
i sometimes use Dziobas Player to play rar'd movies
that way you can preview/stream without unpacking
This, of course, has 0 to do with torrents.Quote:
Originally Posted by Krvaric
back ground information m8.
and since when has anything to do with torrents?
hello, does anyone know any private general 0day tracker with unrarred content?
The OP ( :) ) was concerned with trackers using unrarred scene releases, not the scene. And that whole block of text you pasted stated that uploading a 700mb iso to an FTP server was a no-no. Well, we use the Bittorrent protocol on trackers, not FTP protocol.Quote:
Originally Posted by Krvaric
lolQuote:
Originally Posted by integralThe OP ( :) ) was concerned with trackers using unrarred scene releases, not the scene. And that whole block of text you pasted stated that uploading a 700mb iso to an FTP server was a no-no. Well, we use the Bittorrent protocol on trackers, not FTP protocol.Quote:
Originally Posted by Krvaric
Well, we use the Bittorrent protocol on trackers, not FTP protocol.
where do you think your so precious torrent file is coming from...?
ok gonna spill it all out for you....... background information as in history...where did it come from...why rar it up etc.....need more explanation?
but who gives a shit anyways?
peace out.
Spoiler: Showwhy fix it when it ain't broken.
Yes, yes I do, thanks for asking.Quote:
Originally Posted by ih55m
So good to know that you know :w00t:Quote:
Originally Posted by SgtMajorYes, yes I do, thanks for asking.Quote:
Originally Posted by ih55m
not all the time. rar is inefficient compression tool, and most sites are just trying to keep it in it's "original" format. (just look for yourself... many unpacked rar's are the same size or smaller than the rar'd version, particularly movies & tv shows) The main purpose seems to be so that the rar's can be checked for errors, but the bittorrent protocol does that itself, so rars are redundant and un-needed. It's basically just fanboys of the scene trying to keep thing the way they always have been.Quote:
Originally Posted by Bionic
Agree, this would be awesome if it existed.Quote:
Originally Posted by SgtMajorYes, yes I do, thanks for asking.Quote:
Originally Posted by ih55m
RARs are the plague of internet media.
It will never change though, it's only P2P that complain about RARs.Quote:
Originally Posted by Eargasm
Every tried racing a release with an autoscript from a seedbox, now imagine that on a nix box where you had to go in, unrar, create a new torrent, then upload to the site, you would be last in the race for releases and that wouldn't do for most sites.
RARs are here to stay, no point bitching about it, just have to find the sites that don't do rars then :D
Fortunately I've got a special treatment for RARs. It's called 7zip; however, the RARs stay present on the system for the duration of seeding, which could be a year or longer.
But I do understand their benefit when using FTP.
still no complaint about the way 0day releases are packed
that must be a real head turner :shutup:
noobs noobs noobs... rars are essential when transferring large amounts of data. avoids corruption. RARS <3
Not with Bittorrent.Quote:
Originally Posted by lukee
Yes with Bittorrent.
i can tell you havnt read the entire thread.
Corruption, does happen with Bittorrent, we see it quite often actually.
just because it does not happen to you, does not mean it does not happen, ever.
It doesn't matter what protocol you are using. If the group badly packed the release you wouldnt have to redownload the entire file. if it got corrupted on your harddrive you'd have to redownload the whole file again. i just find it safer to use rars. The only thing i hate about the scne rules for packing is the 0day shit. Zip a rar file? fuck thats so stupid.Quote:
Originally Posted by integralNot with Bittorrent.Quote:
Originally Posted by lukee
I've read most of my thread, including your stories of how Bittorrent can corrupt files.
It's not right for everyone or every tracker, there will always be people who have their feet stuck in cement.
well i would much prefer to download a 50 meg rar again, than a 25 gig PS3 game ISO say. or a 50 gig Blue ray movie.
rar files are very useful in newsgroup communities because they usually need to check the contents, but not that useful in bittorrent communities because bittorrent architecture already handle pieces. So, you are not saving any bandwidth when you download rar files and you don't need to redownload the whole file again if your client or system crashes.
The only thing which benefits users with rar files is the maximization of storage space.
if the release had been unpacked, tested and uploaded unrared there wouldn't have been a badly packed torrent on the tracker in the first place.Quote:
Originally Posted by lukeeIt doesn't matter what protocol you are using. If the group badly packed the release you wouldnt have to redownload the entire file. if it got corrupted on your harddrive you'd have to redownload the whole file again. i just find it safer to use rars. The only thing i hate about the scne rules for packing is the 0day shit. Zip a rar file? fuck thats so stupid.Quote:
Originally Posted by integral
there would have been one unpacked repack version. one torrent less and a lot of saved bandwith.
your argument says rars make sense because rars might be uploaded corrupted which is kind of a contradiction. no rars on a tracker, no need for repacks on a tracker.
if you read the whole thread you'd see that rars are not needed for bittorrent because of the way the protocol handles files. chunks, checksums and verification are the keywords.
the only reason to tolerate them is faster pretimes and less work for the uploader.
it has nothing to do with errors whatsoever.