|
Table of Contents
|
Questions
The.Sopranos.S04E01.HRHDTV.AC3.XviD-FUA nfo?
Can anyone find that nfo? It could be the first HR HDTV release.
The.Unit.S01E04.HD720p.x264-MiRAGETV nfo?
The first ever scene TV-x264 release.
How come most files aren't detected as being different even though the meta data is different?
http://rescene.wikidot.com/undercover-boss-us-s05e14-hdtv-x264-2hd
Burning images and reading them again from DVD
After burning .img and .iso DVDR images, is it possible to have the exact image again? Which tools to use? If it's different, which bytes? Possible to fix? Parity data?
Looking for these files
Some winrar versions, see rar-versions
Answered
How is "MKV/AVI ReSample 1.3" different from ReSample .NET 1.2?
Use http://ilspy.net/ and check. Decompiled sources attached as archive.
https://bitbucket.org/Gfy/pyrescene/issue/40/add-mkv-avi-resample-13-preview
American.Beauty.1999.1080p.BluRay.x264-LEVERAGE
SRS Load Complete... Elapsed Time: 0.04s
Track Extraction Complete... Elapsed Time: 3.51s
Rebuild Complete... Elapsed Time: 3.83s
File Details: Size CRC
------------- --------
Expected : 84.806.617 670063AB
Actual : 84.806.617 2442025B
Rebuild failed for sample: american.beauty.1999.1080p.bluray.x264-leverage-sample.mkv
Checking that sample exists in the specified full file...
Unable to locate track signature for track 1. Aborting.
Corruption detected: Unable to locate track signature for track 1. Aborting. Aborting.
Sample not found in \American.Beauty.1999.1080p.BluRay.x264-LEVERAGE\american.beauty.1999.1080p.bluray.x264-leverage.rar.
File Details: Size CRC
------------- --------
84.806.617 670063AB
Track Details: Track Length
----- -------------
1 73.434.746
2 11.347.208
3 585
Parse Details: Metadata Attachments Track Data Total
----------- ------------ ------------- -------------
24.078 0 84.782.539 84.806.617
Successfully created SRS file: \tmpuzuq3m.pyReScene\Sample\american.beauty.1999.1080p.bluray.x264-leverage-sample.srs
0:01:58.910000
But the srs file on the site created with MKV/AVI ReSample 1.3 does have a match offset stored!
[application_name] => MKV/AVI ReSample 1.3
[sample_name] => american.beauty.1999.1080p.bluray.x264-leverage-sample.mkv
[file_size] => 84806617
[crc32] => 670063ab
[tracks] => Array
(
[0] => Array
(
[track_id] => 1
[track_size] => 73434746
[match_offset_main_movie_file] => 323257270
)
[1] => Array
(
[track_id] => 2
[track_size] => 11347208
[match_offset_main_movie_file] => 323372471
)
[2] => Array
(
[track_id] => 3
[track_size] => 585
[match_offset_main_movie_file] => 331429959
)
The exe is able to reconstruct the sample file!
The.LadyKillers.2004.720p.iNTERNAL.HDTV.x264-DEADPOOL
Is able to reconstruct only with the preview version.
Solution
The changes were implemented in pyReScene early 2015.
http://pastebin.com/eTSai7jb
<shEiD> Unable to locate track signature for track 2. Aborting.
[06-Dec-2010/03:29:28] <shEiD> but just now I went to the site and saw that gui version is out :)
[06-Dec-2010/03:29:31] <@umlaut> oh yeah. you probably want that new secret build that i've been keeping to myself
[06-Dec-2010/03:29:37] <@umlaut> just a sec
[06-Dec-2010/03:29:47] <shEiD> tried that same release with gui version and it created an srs without a hitch :)
[06-Dec-2010/03:30:12] <@umlaut> oh, i don't think the gui does the -c option?
[06-Dec-2010/03:30:30] <@umlaut> it's probably to do with mkv header compression/stripping
[06-Dec-2010/03:30:40] <shEiD> lemme check, i dont even remember now whats taht -c option
[06-Dec-2010/03:31:01] <@umlaut> it checks to make sure the tracks can be matched before creating the srs
[06-Dec-2010/03:31:20] <shEiD> yes, it has a checkbox option for -c
[06-Dec-2010/03:31:38] <@umlaut> probably won't work if you check the box ;)
[06-Dec-2010/03:31:48] <shEiD> I did check it :)
[06-Dec-2010/03:31:50] <@umlaut> if a full mkv doesn't have header stripping but the sample does, they won't match without some compensation. i made a new version that handles it
[06-Dec-2010/03:33:54] <shEiD> ok, 1 sec, I'll throw both out puts to pastebin
[06-Dec-2010/03:33:55] <@umlaut> http://rescene.com/resample/srs.1.3.preview.zip <— try that one
[06-Dec-2010/03:34:22] <shEiD> oh, new version… :)
How come the expected size is so small for the MKV?
Warning: File size does not appear to be correct!
Expected: 52
Found: 20.971.520
Corruption detected: Invalid element length at 0x013E4BEF. Aborting.
http://www.srrdb.com/release/details/Susi.und.Strolch.2.2001.German.DL.1080p.BluRay.x264-DETAiLS
The file is corrupt. MKVInfo shows the following information:
(MKVInfo) + EBML head
(MKVInfo) |+ EBML version: 1
(MKVInfo) |+ EBML read version: 1
(MKVInfo) |+ EBML maximum ID length: 4
(MKVInfo) |+ EBML maximum size length: 8
(MKVInfo) |+ Doc type: matroska
(MKVInfo) |+ Doc type version: 2
(MKVInfo) |+ Doc type read version: 2
(MKVInfo) + Segment, size 0
(MKVInfo) |+ EbmlVoid (grootte: 4096)
VLC plays the first 22 seconds of the sample, but can't seek nor show the file length.
Susi und Strolch 2: Kleine Strolche - Großes Abenteuer! (2001) is shown as title.
Further investigation shows the 40 byte EBML element is there. The segment that follows is only 12 bytes large. It contains the id and size fields. The size field is set to 0 bytes instead of the correct amount. No further parsing and data is expected.
My guess is that the sample was already copied/spread before it was completely created/written.
How come the expected size is so small for the MP4?
Warning: File size does not appear to be correct!
Expected at least: 48
Found : 3.543.040
Error: Parsed size does not equal file size.
The sample is likely corrupted or incomplete.
http://www.srrxxx.com/release/details/BigNaturals.10.04.07.Kassandra.Retro.Beauty.XXX.HR.MP4-SEXORS
SRS shows the following:
Warning: File size does not appear to be correct!
Expected at least: 48
Found : 3.543.040
File Details: Size CRC
------------- --------
3.543.040 63A0E111
Track Details: Track Length
----- -------------
Parse Details: Metadata Stream Data Total
----------- ------------- -------------
48 0 48
Error: Parsed size does not equal file size.
The sample is likely corrupted or incomplete.
The number in the size field of the mdat atom is larger than the bytes it contains.
The expected size could be higher and more exact here, even though no track info is found. Track info can be placed at the end. Fixed as follows:
Warning: File size does not appear to be correct!
Expected at least: 13.929.909
Found : 3.543.040
File Details: Size CRC
------------- --------
3.543.040 63A0E111
Track Details: Track Length
----- -------------
Parse Details: Metadata Stream Data Total
----------- ------------- -------------
48 0 13.929.909
Error: Parsed size does not equal file size.
The sample is likely corrupted or incomplete.
What data are the QuickSFV comments based on?
An example at the end of an SFV file:
cowiso-xvid-yrrol.part48.rar 60C3AB2E
cowiso-xvid-yrrol.part49.rar E50D18BC
;Q2-1c25890ae82a640
;Q2-8KmPHkmiwgE=
;Q2-////////gA==
moc.liamtoh|vfskciuq#moc.liamtoh|vfskciuq
550 Requested action not taken: mailbox unavailable