@admin: would you able to Enable Crocko on Mirrorstack please? the upload fail problem that used to occur before should be fixed by Mirrorstack by now :)
Well I went back and re-downloaded the Fairy Tail and extracted it with 7z 9.25 and I didn't get an error. I uninstalled 7z 9.20. So it looks like for people who have 7z 9.20 would have to update to 9.25 and it should work no problem but you may get an occasional failure if so then re-download and try again. And to be on the safe side of things check the CRC with Rapid CRC or Anime Checker.
Urgh all of them do give an error for me, and my guess is that they're random bit flips :/
[IB] Mondaiji-tachi ga Isekai kara Kuru Sou Desu yo - 05 [720p] [10bit] [D1705E86].mkv Archive file: 1360501961576.7z (MD5: 009ec4697ab8c3cd07eb38cbb4a5d2e4) Byte 0x1fc5faf is 0x7c (1111100 in binary) but should be 0x78 (1111000 in binary) Byte 0x49d93ab is 0x6d (1101101) but should be 0x69 (1101001) Byte 0xab13baf is 0x58 (1011000) but should be 0x59 (1011001) (there's more for this file)
[CureCom] DokiDoki! Precure - 01 [720p][F943F56C].mkv Archive file: 1360503954441.7z (MD5: 41ebe438edef70eb4dbde94bd5b3539e) Byte 0x11e239af is 0x5d (1011101 in binary), but should be 0x59 (1011001 in binary)
Once you make the above single bit changes they extract fine. The thing that needs to be figured out is whether the corruption comes from my script or file transfer. Because these are all single bit flips, my instinct is with transmission, or something at AnonFiles, in which case, I probably can't do much about it.
- Update - Okay, there definitely is a problem with AnonFiles. I just redownloaded 1360501961576.7z ([IB] Mondaiji-tachi ...) and got an MD5 of 8a795b6514beec9b2d748124148ff606 In simpler terms, this means that AnonFiles is corrupting the data sent back randomly. I'll do some further investigation on this a bit later.
- Update 2 - I think some of the MD5s I stuffed up above, but anyway, just downloaded 1360501961576.7z a few times, and AnonFiles seems to be spitting out different files each time! (none of which extract without error)
I may look into seeing how they're stuffing up later, but I'll likely remove AF soon because of these random corruptions.
I may consider doing byte swap encoding rather than delta coding, where single bit flips won't cause the entire file to corrupt (though you'll still get CRC errors). Thanks for the examples.
Unfortunately, even if .mkv is allowed, there's a number of problems: a) files that exceed 500MB will need to be split (and thus won't have a .mkv extension) b) they seem to be doing a header check, so files that don't have a proper MKV header, even if the extension is .mkv may be rejected - I suppose these are rare, but I don't want to deal with such a possibility c) non-MKV files may still need to be wrapped
So for simplicity's sake, I'm going to wrap everything in a .7z The only real solution is if they remove the file type check altogether.
I got them for [Tsuki]_Fairy_Tail_-_168_[1280x720][F74BA608].mkv and [CureCom] DokiDoki! Precure - 01 [720p][F943F56C].mkv I haven't tired any other one's yet since those two failed on me.
Has anyone had this problem with Anonfiles I downloaded two different files from there and when I went to extract them on both files it said CRC failed file is broken. I used 7z to extract them has well.
didn't know about hardware/software decoder thing. will check it. btw i found a site with 576p re-encodes. file sizes are also less than 100mb :) sorry for bothering you.
Although not solving your issue, I might point out that if your phone is decoding video via a hardware decoder, the resolution won't affect battery usage (in any meaningful way at least). If you're using a software decoder, well, only more recent phones actually have the CPU power to do such a thing reasonably, and these all have hardware decoders.
You might find that reducing resolution doesn't really reduce sizes that much. Though you could probably shave most episodes down to around 100-150MB at 576p with not too much quality loss if you tried.
If you're happy with asking a server to do it, why not try asking others to do it instead?
I suppose so, just the question somewhat is... perhaps it's more relevant to comment at the source (ie Nyaa)? Other thing is how to display the link, since skipped stuff go directly to source. (actually, it's already possible to comment on these, if you can figure out the URL to them)
DeadFish is re-encode group but file sizes are still 200MB+ & they only do 720p which becomes storage issue in mobile devices & 720p drains batt. fast. DeadFish is also probably using some dedi server.
On Request re-encode might be better option, so users will select video resolution 480/576 & click request button & Server will add it to encode queue mp4 format is easily supported by mobile devices as long as its 8-bit & Quality is lot better than old Xvid avi format.
The main problem with this is that it requires a dedicated server with a fairly beefy CPU - not cheap. Other issues would include the fact that anime encoders tend to be rather exotic in their choice of formats they encode into, meaning that an automatic encode process could be difficult. Filtering out duplicates could be problematic too.
So it's not planned, but some groups like DeadFish seem to be doing re-encodes anyway...?
@admin: re-encoding anime to small size 1024x576p, 75mb, mp4, hardsub, 8-bit planned in near future on AT? re-encoding 720p releases here into 576p mini encodes would allow playing/saving files on mobile devices easily & will be lot easier to download for users with very slow download speed :)
Thanks for the comment, I'll keep that in mind. For now, I think the fact that we're a very small site that we're largely out of the radar of anything. We can see what happens to larger sites first and act accordingly if necessary.
not sure. Mega did say to share keys via secure channels or something if someone develop a site similar to tuxfire that can convert keys to something else that we can share securely without revealing real key. if its possible to do that...
Mega Implications for AT: For any who didn't know, the founder of MU started a new file storage service, "Mega". The twist is that all files have to be encrypted so Mega doesn't and can't know the contents. If this succeeds as a legal defense for download services, there are several implications for us:
1. It will provide a model for download services to survive and thrive as businesses. Good for us. 2. DMCA will have to come to the portals to get links and passwords. They will try to automate harvesting as much as possible to keep costs down. 3. DMCA enforcement letters will probably have to come to the portals instead of the download service as well. This is bad for them (swatting mosquitoes instead of shooting an elephant), but may create difficulties for us as well.
First Suggestions: 1. Show titles and other sensitive information should be contained in photo images, not plain text. Make it hard for bots to harvest. 2. Comments section should have auto-correction to substitute for a list of trigger words, such as the names of certain companies like 'Funny-mae-shin' so our users can't accidentally hang a target on our backs. (In a recent example, if you Googled that company, an AT page was one of the first three hits for a while. That's not good. And the links on that page went dead very fast.) 3. ?
12/02/2013 07:01 * — dark