Activity for i30817
-
i30817 modified a comment on ticket #2056
Do you have the ophidian sword that elderly xena is supposed to give you? It's also a key item to kill the earth serpent, and there is supposed to be a bug (not in si fixes iirc) where she doesn't and you're screwed. http://wiki.ultimacodex.com/wiki/Ophidian_Sword Granted the stupid serpent could tell you that it's the only sword that will kill it if it's that.
-
Do you have the ophidian sword that elderly xena is supposed to give you? It's also a key item to kill the earth serpent, and there is supposed to be a bug (not in si fixes iirc) where she doesn't and you're screwed. http://wiki.ultimacodex.com/wiki/Ophidian_Sword
-
Do you have the ophidian sword that elderly xena is supposed to give you? It's also a key item to kill the earth serpent, and there is supposed to be a bug (not in si fixes iirc) where she doesn't and you're screwed.
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Probably because it's a loop device not a real drive, so the ioctls are returning weird values. I tried to print it and ' iRes1 = ioctl(iFd, BLKGETSIZE, &lSectors);' makes iRes1 0 and ' iRes2 = ioctl(iFd, HDIO_GETGEO, &sGeometry);' makes iRes2 -1 then if(! (iRes1 && iRes2) ) return sGeometry.start; the inner is false because of iRes2, so it returns the uninit value. This seems wrong. Could we get a command line switch to...
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Probably because it's a loop device not a real drive, so the ioctls are returning weird values. I tried to print it and ' iRes1 = ioctl(iFd, BLKGETSIZE, &lSectors);' makes iRes1 0 and ' iRes2 = ioctl(iFd, HDIO_GETGEO, &sGeometry);' makes iRes2 -1 then if(! (iRes1 && iRes2) ) return sGeometry.start; the inner is false because of iRes2, so it returns the uninit value. This seems wrong. Could we get a command line switch to...
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Could we get a command line switch to provide this 'sGeometryStart'? Could it double as the 'offset' to operate on files without sudo if the given file is a real file?
-
Actualy it's not the max long but the uninitialized value of sGeometry.start. Could we get a command line switch to provide this 'sGeometryStart'? Could it double as the 'offset' to operate on files without sudo?
-
Using -p with a loopback device under dos causes the number of hidden sectors to be the max long
-
Enhance IMGMOUNT to be able to optinally mount dirs on cues like mount
-
Support for extended attributes
-
To be honest, i dont know what this bug is about anymore so it can be closed.
-
bump. It finally happened that scummvm is supporting a game that needs this to share a single set of data files for both running the dos and scummvm version (versailles 1685, if you're wondering).
-
The usecase i'm most interested ATM is creating a gd-rom patcher (much like patchy 98 for floppy/hard disks for the pc-98) https://46okumen.com/pachy98/ Translations and 'final rom' hashes for the dreamcast would get much easier to archive if their patches didn't lead to 400mb binary xdeltas and if hackers didn't insist in releasing complete images on outdated dumps or formats (cdi and alchool comes to mind), and a fileformat aware patcher could do that (because dreamcast games aren't in the habit...
-
The usecase i'm most interested ATM is creating a gd-rom patcher (much like patchy 98 for floppy/hard disks for the pc-98) https://46okumen.com/pachy98/ Translations for the dreamcast would get much easier to archive if their patches didn't lead to 400mb binary xdeltas and if hackers didn't insist in releasing complete images on outdated dumps or formats (cdi and alchool comes to mind), and a fileformat aware patcher could do that (because dreamcast games aren't in the habit of packing their files...
-
The usecase i'm most interested ATM is creating a gd-rom patcher (much like patchy 98 for floppy/hard disks for the pc-98) https://46okumen.com/pachy98/ Translations for the dreamcast would get much easier to archive if their patches didn't lead to 400mb binary xdeltas and if hackers didn't insist in releasing complete images on outdated dumps or formats (cdi and alchool comes to mind), and a fileformat aware patcher could do that (because dreamcast games aren't in the habit of packing their files...
-
The usecase i'm most interested ATM is creating a gd-rom patcher (much like patchy 98 for floppy/hard disks for the pc-98) https://46okumen.com/pachy98/ Translations for the dreamcast would get much more easier to archive if their patches didn't lead to 400mb binary xdeltas, and a fileformat aware patcher could do that (because dreamcast games aren't in the habit of packing their files in a virtual filesystem). It would seem that libmirage would be ideal for the backbone of a fileformat aware patcher...
-
I think it's time to close this, since i figured out what i needed. Even if it's not doing 'completely the right thing' for Mode 2 Mixed tracks , it's still enough to get the file that i want - SYSTEM.CNF - in all examples i tried. Apparently those sectors are reserved to video files not text or even sony wanted to simplify the parsing here. edit: doh, can't find a user close button in sourceforge.
-
I think it's time to close this, since i figured out what i needed. Even if it's not doing 'completely the right thing' for Mode 2 Mixed tracks , it's still enough to get the file that i want - SYSTEM.CNF - in all examples i tried. Apparently those sectors are reserved to video files not text or even sony wanted to simplify the parsing here.
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: metroid prime trilogy at least has a segment that is not zero filed (some others also have this one, and some have isolated...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: metroid prime trilogy at least has a segment that is not zero filed (some others also have this one, and some have isolated...
-
Well, i'll let you be the judge of that. edit: doh, those were the locations of the bytes. First collumn is a location in od output. No, it appears to be all zero, nvm.
-
edit: see post bellow instead
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: metroid prime trilogy at least has a segment that is not zero filed (some others also have this one, and some have isolated...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: metroid prime trilogy at least has a segment that is not zero filed (some others also have this one, and some have isolated...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: metroid prime trilogy at least has a segment that is not zero filed (some others also have this one, and some have isolated...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: from 327672 (04fff8) to show what appears to be a pattern after a lot of zero fills: https://gist.github.com/i30817/b37edc7dd61dd478efa6fdd9988ed9b5...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: from 327672 (04fff8) to show what appears to be a pattern after a lot of zero fills: https://gist.github.com/i30817/b37edc7dd61dd478efa6fdd9988ed9b5...
-
Well, i'll let you be the judge of that. edit: doh, those were the locations of the bytes. No, it appears to be all zero, nvm.
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: from 327672 (04fff8) to show what appears to be a pattern after a lot of zero fills: https://gist.github.com/i30817/b37edc7dd61dd478efa6fdd9988ed9b5...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it was in little endian, vbindiff outputs big endian for some reason. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: from 327672 (04fff8) to show what appears to be a pattern after a lot of zero fills: https://gist.github.com/i30817/b37edc7dd61dd478efa6fdd9988ed9b5...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it's in little endian. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: from 327672 (04fff8) to show what appears to be a pattern after a lot of zero fills: https://gist.github.com/i30817/b37edc7dd61dd478efa6fdd9988ed9b5 Though metroid...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it's in little endian. If you'd prefer a switched listing just ask me. Or hell, i'll do it now: from 327672 (04fff8) to show what appears to be a pattern after a lot of zero fills: https://gist.github.com/i30817/b37edc7dd61dd478efa6fdd9988ed9b5 Though metroid...
-
Ok, i've read od manpage with more attention and the command should have been: find . -depth -type f -iname "*.iso" -printf '%p\n' -exec od --endian big -Ax -x -j327672 -N240 {} \; in order to mimic the output of vbindiff exactly, currently it's in little endian. If you'd prefer a switched listing just ask me.
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them. In actual hexadecimal (i could have swore -Ax was it on the od manpage but whatever) it appears to translate to '5D 1C 9E A3 ' Maybe it's useless and it's just a common offset, not a actual id. Damn thoughtless scrubbers. edit: my trauma team iso only started...
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them. In actual hexadecimal (i could have swore -Ax was it on the od manpage but whatever) it appears to translate to '5D 1C 9E A3 ' Maybe it's useless and it's just a common offset, not a actual id. Damn thoughtless scrubbers. edit: my trauma team iso only started...
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them. In actual hexadecimal (i could have swore -Ax was it on the od manpage but whatever) it appears to translate to '5D 1C 9E A3 ' Maybe it's useless and it's just a common offset, not a actual id. Damn thoughtless scrubbers. edit: my trauma team iso only started...
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them. In actual hexadecimal (i could have swore -Ax was it on the od manpage but whatever) it appears to translate to '5D 1C 9E A3 ' Maybe it's useless and it's just a common offset, not a actual id. Damn thoughtless scrubbers. edit: my trauma team iso only started...
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them. In actual hexadecimal (i could have swore -Ax was it on the od manpage but whatever) it appears to translate to '5D 1C 9E A3 ' Maybe it's useless and it's just a common offset, not a actual id. Damn thoughtless scrubbers.
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them. In actual hexadecimal (i could have swore -Ax was it on the od manpage but whatever) it appears to translate to '5D 1C 9E A3 '
-
Same thing but from offset 0. Remember, first column are offsets in od output (that was my mistake above). https://gist.github.com/i30817/c5f5992df47e002e40f9cfff46bc6aa2 It appears that 'for some reason' '016135 121636' repeats on all of them.
-
Well, i'll let you be the judge of that. edit: doh, those were the locations of the bytes. No, it appears to be all zero, nvm. It's promissing at least. 'Starts with 002460 zero until it ends with 002550' seems to hold across this small collection (small in #, i assure you it's huge in gb). The zero part appears to indicate it was scrubbed partially though. I'm not actually sure, because it appears that the srub standard is sometimes FF instead of 00 and it appears that part of the disk are filled...
-
Well, i'll let you be the judge of that. It's promissing at least. 'Starts with 002460 zero until it ends with 002550' seems to hold across this small collection (small in #, i assure you it's huge in gb). The zero part appears to indicate it was scrubbed partially though. I'm not actually sure, because it appears that the srub standard is sometimes FF instead of 00 and it appears that part of the disk are filled with FF too (maybe the dolphin scrubber applied on top of a already FF scrubbed disc?)....
-
Well, i'll let you be the judge of that. It's promissing at least. 'Starts with 002460 zero until it ends with 002550' seems to hold across this small collection (small in #, i assure you it's huge in gb). The zero part appears to indicate it was scrubbed partially though.
-
Well, i'll let you be the judge of that. It's promissing at least. 'Starts with 002460 zero until it ends with 002550' seems to hold across this small collection (small in #, i assure you it's huge in gb). The zero part appears to indicate it was scrubbe though.
-
Well, i'll let you be the judge of that. It's promissing at least. 'Starts with 002460 zero until it ends with 002550' seems to hold across this small collection (small in #, i assure you it's huge in gb).
-
Well, i'll let you be the judge of that. It's promissing at least. 'Starts with 002550 zero until it ends with 002550' seems to hold across this small collection (small in #, i assure you it's huge in gb).
-
In a way, it's a pity that NASOS (a lossless 'encoder' of the 'random' trash data that Nintendo used to fill space on the gcm) was obviously the result of IDA reverse engineering from a leaked Nintendo tool If the algorithm was trully reversed, removing this data + a seed (basically what NASOS does) would make it a ideal target for CDEmu and for space efficiency for these, without upsetting purist redump projects. As it is, no wonder that open source projects like dolphin consider the fileformat...
-
In a way, it's a pity that NASOS (a lossless 'encoder' of the 'random' trash data that Nintendo used to fill space on the gcm) was obviously the result of IDA reverse engineering from a leaked Nintendo tool. If the algorithm was trully reversed, removing this data + a seed (basically what NASOS does) would make it a ideal target for CDEmu and for space efficiency for these, without upsetting purist redump projects. As it is, no wonder that open source projects like dolphin consider the fileformat...
-
In a way, it's a pity that NASOS (a lossless 'encoder' of the 'random' trash data that Nintendo used to fill space on the gcm) was obviously the result of IDA reverse engineering from a Nintendo tool. If the algorithm was trully reversed, removing this data + a seed (basically what NASOS does) would make it a ideal target for CDEmu and for space efficiency for these, without upsetting purist redump projects. As it is, no wonder that open source projects like dolphin consider the fileformat taint...
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. No, without i it just calls them 'data' 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern. But if it preserves for you now, i believe you shouldn't have to do anything. Though i...
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern. But if it preserves for you now, i believe you shouldn't have to do anything. Though i must mention that it seems like at least...
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern. But if it preserves for you now, i believe you shouldn't have to do anything. Though i must mention that it seems like at least...
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern. But if it preserves for you now, i believe you shouldn't have to do anything. Though i must mention that it seems like at least...
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern. But if it preserves for you now, i believe you shouldn't have to do anything. Though i must mention that it seems like at least...
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern. But if it preserves for you now, i believe you shouldn't have to do anything.
-
It's actually possible i simply did this process during a earlier version of dolphin that did things differently. 0000 001C: 00 00 00 00 54 52 41 55 4D 41 20 54 45 41 4D 00 ....TRAU MA TEAM. 0000 001C: 00 00 00 00 54 48 45 20 4C 41 53 54 20 53 54 4F ....THE LAST STO 0000 001C: 00 00 00 00 54 61 6C 65 73 20 6F 66 20 53 79 6D ....Tale s of Sym well, you can see the pattern.
-
BTW, did you try a game that was first compressed on dolphin and then extracted (right click on the game list)? I believe dolphin and some other tools remove or zero-fill 'trash' / data that Nintendo put there just to increase filesize when that is done. I'm only asking because when i use file -i * on my collection of gamecube and wii isos i only get application/octet-stream; charset=binary not application/x-gamecube-iso-image or whatever, so it's a question if the tools are doing it wrong (dolphin...
-
BTW, did you try a game that was first compressed on dolphin and then extracted (right click on the game list)? I believe dolphin and some other tools remove or zero-fill 'trash' / data that Nintendo put there just to increase filesize when that is done. I'm only asking because when i use file -i * on my collection of gamecube and wii isos i only get application/octet-stream; charset=binary not application/x-gamecube-iso-image or whatever, so it's a question if the tools are doing it wrong (dolphin...
-
BTW, did you try a game that was first compressed on dolphin and then extracted (right click on the game list)? I believe dolphin and some other tools remove 'trash' data that Nintendo put there just to increase filesize. I'm only asking because when i use file -i * on my collection of gamecube and wii isos i only get application/octet-stream; charset=binary not application/x-gamecube-iso-image or whatever, so it's a question if the tools are doing it wrong (dolphin and others) and if cdemu loaded...
-
BTW, did you try a game that was first compressed on dolphin and then extracted (right click on the game list)? I believe dolphin and some other tools remove 'trash' data that Nintendo put there just to increase filesize. I'm only asking because when i use file -i * on my collection of gamecube and wii isos i only get application/octet-stream; charset=binary not application/x-gamecube-iso-image or whatever, so it's a question if the tools are doing it wrong (dolphin and others) and if cdemu loaded...
-
BTW, did you try a game that was first compressed on dolphin and then extracted (right click on the game list)? I believe dolphin and some other tools remove 'trash' data that Nintendo put there just to increase filesize. I'm only asking because when i use file -i * on my collection of gamecube and wii isos i only get application/octet-stream; charset=binary not application/x-gamecube-iso-image or whatever, so it's a question if the tools are doing it wrong (dolphin and others) and if cdemu loaded...
-
BTW, did you try a game that was first compressed on dolphin and then extracted (right click)? I believe dolphin and some other tools remove 'trash' data that Nintendo put there just to increase filesize. I'm only asking because when i use file -i * on my collection of gamecube and wii isos i only get application/octet-stream; charset=binary not application/x-gamecube-iso-image or whatever, so it's a question if the tools are doing it wrong (dolphin and others) and if cdemu loaded there, would it...
-
Thanks!
-
Nintendo optical discs support in libmirage
-
GDI file support.
-
It wouldn't unfortunately, the sony serial format is clear. The code i atached above looks alright (though i'm not a good programmer) but in practice fails harder than yours - besides being slower. I don't really know if it's because of a bug there or a problem in pycdlib with 2324 user data sectors, but i think i give up trying to make mode2 form2 sectors work. Your original truncation works well enough to extract and access text files, and that is all i want.
-
Here is the wrapper code (along with the application code eh)
-
Ok, i think i managed. A question, why does libmirage start sector of a track is 'negative' (-150) but the actual disc data from the track appears to always start at sector 0? I don't really understand it but to iterate over the 'useful sectors' i had to do this: for i in range(0, self.track.layout_get_start_sector() + self.track.layout_get_length()): instead of this: for i in range(self.track.layout_get_start_sector(), self.track.layout_get_start_sector() + self.track.layout_get_length()): I also...
-
Ok, i think i managed. A question, why does libmirage start sector of a track is 'negative' (-150) but the actual disc data from the track appears to always start at sector 0? I don't really understand it but to iterate over the 'useful sectors' i had to do this: for i in range(0, self.track.layout_get_start_sector() + self.track.layout_get_length()): instead of this: for i in range(self.track.layout_get_start_sector(), self.track.layout_get_start_sector() + self.track.layout_get_length()):
-
Mmm. Nasty. The seek to calculate size and getting the user data is wrong then. Anyway to tell the size of a sector in libmirage? Is it just 'len(get_sector(int))'? And the number of sectors is really disc.get_track_by_index(0).track.layout_get_length() or is there a better way to iterate over the tracks? I'm getting "mirage-error: Sector address out of range! (7)" exceptions if it try to iterate over sectors based on the number on track.layout_get_length()
-
Mmm. Nasty. I'm going to keep on assuming that the stuff i want is on the 2048 user data sectors both because i haven't seen a example otherwise and because all redump files i mount in cdemu allow me to get the text file i want to parse with this utility. Mixed mode was used for video if wikipedia is right so... The seek to calculate size is wrong then. Anyway to tell the size of a sector in libmirage? Is it just 'len(get_sector(int))'?
-
btw we can get the number of bytes on the 'user data' of a track without iterating over all sectors with get_sector.get_data().length (using self.track.layout.get_length()) or do we definitely need it? edit: like self.track.layout.get_length() * 2048 == number of bytes in the 'user data' from get_data() on all the sectors. There isn't a gotcha like the last sector not having 2048 bytes or something here right?
-
btw we can get the number of bytes on the 'user data' of a track without iterating over all sectors with get_sector.get_data().length (using self.track.layout.get_length()) or do we definitely need it? edit: apparently not. Is there a method to get the length, or do i pay for the iteration?) Eh. I'm doing it. There isn't a gotcha like the last sector being not being always 2048 too if i count it like this right?
-
btw we can get the number of bytes on the 'user data' of a track without iterating over all sectors with get_sector.get_data().length (using self.track.layout.get_length()) or do we definitely need it? edit: apparently not. Is there a method to get the length, or do i pay for the iteration?) Eh. I'm doing it. I need this to make the seek method of your adapter compatible with the os.SEEK_END optional paramenter, which adds the pos relative to the end of the file.
-
btw we can get the number of bytes on the 'user data' of a track without iterating over all sectors with get_sector.get_data().length (using self.track.layout.get_length()) or do we definitely need it? I need this to make the seek method of your adapter compatible with the os.SEEK_END optional paramenter, which adds the pos relative to the end of the file.
-
btw we can get the number of bytes on the 'user data' of a track without iterating over all sectors with get_sector.get_data().length (self.track.layout.get_length()) or do we definitely need it? I need this to make the seek method of your adapter compatible with the os.SEEK_END optional paramenter, which adds the pos relative to the end of the file.
-
Yeah i figured t out after looking at the wikipedia page on the cd modes like i should have before. Libmirage tracks/sectors don't actually store those extra bytes per sector (sync pattern, address, mode, subheader, error detection and error correction bytes) right?
-
Ok, unfortunately i spoke too soon. This basically worked, except on some cases. More info is here: https://github.com/clalancette/pycdlib/issues/3 This is not really your business, but i just thought to mention it. Even with your valuable help, and with the trick of transforming the track information to seperate sectors, that trick doesn't really work if the underlying isos are not 2048 byte sectors but 2352 sectors (as most psx1 dumps). I'll try to read it as 2352 in the reader from the libmirage...
-
Thank you! That example was just what i needed. Now i don't have to deal with temperamental OS mounts and there is the possibility of making this somewhat portable.
-
Would you be willing to add file extraction and listing support to libmirage?
-
Using the example of image-analyser it was easy to create a extraction tool for the header. But is it possible to extract a file from the disc without using cdemu from the cmd line. I only really need to grep a single file from ps1 discs 'system.cnf', and it would be nice to do it from python (using libmirage or another library) without using the cdemu cmdline tool and interacting with the linux mount cmd.
-
Forgot to mention, you can see what part of the header is the 'serial number' by using the redump site. For example, for Sega Saturn you can use: http://redump.org/discs/system/ss to figure out the serial is the 'GS-9184' in dragon force II header there, ie: it's right after 'SEGA SEGASATURN SEGA ENTERPRISES' Bulk Smash otoh has it marked as 'T-14310G' which is right before 'SEGA SEGASATURN SEGA TP T-143 ' which, by not so surprising reasons are the same number of letters, so the parsing seems straightfoward....
-
Forgot to mention, you can see what part of the header is the 'serial number' by using the redump site. For example, for Sega Saturn you can use: http://redump.org/discs/system/ss to figure out the serial is the 'GS-9184' in dragon force II header there, ie: it's right after 'SEGA SEGASATURN SEGA ENTERPRISES' Bulk Smash otoh has it marked as 'T-14310G' which is right before 'SEGA SEGASATURN SEGA TP T-143 ' which, by not so surprising reasons are the same number of letters, so the parsing seems straightfoward....
-
Forgot to mention, you can see what part of the header is the 'serial number' by using the redump site. For example, for Sega Saturn you can use: http://redump.org/discs/system/ss to figure out the serial is the 'GS-9184' in dragon force II header there, ie: it's right after 'SEGA SEGASATURN SEGA ENTERPRISES' Bulk Smash otoh has it marked as 'T-14310G' which is right before 'SEGA SEGASATURN SEGA TP T-143 ' which, by not so surprising reasons are the same number of letters, so the parsing seems straightfoward....
-
Forgot to mention, you can see what part of the header is the 'serial number' by using the redump site. For example, for Sega Saturn you can use: http://redump.org/discs/system/ss to figure out the serial is the 'GS-9184' in dragon force II header there, ie: it's right after 'SEGA SEGASATURN SEGA ENTERPRISES' Bulk Smash otoh has it marked as 'T-14310G' which is right before 'SEGA SEGASATURN SEGA TP T-143 ' which, by not so surprising reasons are the same number of letters, so the parsing seems s...
-
CHD supports cd images too now. From what i can see it's used on mame pretty generally now that it merged with MESS and it's probably going to get more popular now that Retroarch is trying to support it (badly) and MAME is starting get into psx cd dumps territory.
-
Create a tool which only extracts proprietary serial ids from disc images
-
I'd honestly prefer qcow2 because of the snapshot function. If it was a efficient implementation, its copy on write properties would allow better efficiency when you need to copy the smaller snaphot to disk (in a larger copy-on-write filesystem). Assuming the backing image is never modified after you do a snapshot of course. Also, the obvious advantage of having a canonical backup.
-
Bring mount folder as cdrom to feature parity with disc image support
-
Make append function more useful
-
Desmume gtk port can't open roms in zip files
-
Grrr, never mind, i'd forgotten about the rest of the data files and just assumed...
-
Return to Zork cd version crashes on start
-
On second thought no skin off my back if you don't want to support it. I can always...
-
I really think scummvm should parse cue files when it finds it instead for both dosbox...
-
I really think scummvm should parse cue files when it finds it instead for both dosbox...
-
I really think scummvm should parse cue files when it finds it instead for both dosbox...
-
I really think scummvm should parse cue files when it finds it instead for both dosbox...
-
I really think scummvm should parse cue files when it finds it instead for both dosbox...
-
I really think scummvm should parse cue files when it finds it instead for both dosbox...
1 >
