Menu
▾
▴
linuxsampler-devel
|
From: Jaime T <eno...@gm...> - 2017-11-01 13:17:05
|
Hi all. I use linuxsampler with various pianos, and I thought I'd try out the gig file integrity check offered by gigdump (using a very recent self-compile from subversion). I was surprised to find the following results: Tascam's "original" nemesys gigapiano (.gig md5sum: 0175...): Verifying sample checksum table ... DAMAGED Artvista's Malmsjo Acoustic Grand (.gig md5sum: 886b...): Verifying sample checksum table ... DAMAGED Tascam BG (Biggagigga/Purgatory Creek) Rhodes (md5sum: 0fa5...): Verifying sample checksum table ... DAMAGED Could anyone please give me an idea of what is causing this? I can provide any diagnostic info required and/or I can upload these to cloud-storage if needed. Many thanks, Jaime |
|
From: Christian S. <sch...@li...> - 2017-11-01 19:31:50
|
On Mittwoch, 1. November 2017 13:16:58 CET Jaime T wrote: > Tascam BG (Biggagigga/Purgatory Creek) Rhodes (md5sum: 0fa5...): > Verifying sample checksum table ... DAMAGED > > Could anyone please give me an idea of what is causing this? I can > provide any diagnostic info required and/or I can upload these to > cloud-storage if needed. If the integrity check for a sample failed, gigdump prints you both the expected checksum, as well as the actual checksum it calculated. Compare the two checksums printed on the screen. If they simply look mirrored like: "aabbccdd" vs "ddccbbaa" then simply ignore this error. That was a bug in libgig before and your samples are fine. And in that case you can simply run gigdump --rebuild-checksums foo.gig to get rid of this false error in the file. If however the two printed checksums look completely different, then your samples "may be" damaged. But again, there was a bug in libgig before where not all sample checksums were updated after making certain modifications with libgig (i.e. using gigedit) before. So in that case you might need to check the individual samples manually (i.e. with your ear), because there might be potentially noise, clicks or something like that. And again if all sounds fine run gigdump --rebuild-checksums foo.gig See also man gigdump About one year ago, when I accidentally damaged one of my gig files and actually started using this feature, I actually found out that there were several bugs regarding those checksums, editing and integrity check for many years without anybody noticing it. I fixed them, so it should work fine now. CU Christian |
|
From: Jaime T <eno...@gm...> - 2017-11-03 09:33:21
|
On 1 November 2017 at 19:31, Christian Schoenebeck <sch...@li...> wrote: > If the integrity check for a sample failed, gigdump prints you both the > expected checksum, as well as the actual checksum it calculated. Compare the Hi Christian. I'm using subversion revision 3363 (on a "fresh" debian stretch), and I'm not seeing the output that you have described. Here's the whole output: $ gigdump --verify gigapiano.gig Verifying sample checksum table ... DAMAGED You may use --rebuild-checksums to repair the sample checksum table. $ I haven't dived into the source, but I'm assuming that gigdump will only print the expected and actual checksums if it finds what it thinks is a "meaningful" checksum table (which perhaps it hasn't done in my case!) With best wishes, Jaime |
|
From: Christian S. <sch...@li...> - 2017-11-03 10:34:39
|
On Freitag, 3. November 2017 09:33:08 CET Jaime T wrote: > $ gigdump --verify gigapiano.gig > Verifying sample checksum table ... DAMAGED > You may use --rebuild-checksums to repair the sample checksum table. > $ > > I haven't dived into the source, but I'm assuming that gigdump will > only print the expected and actual checksums if it finds what it > thinks is a "meaningful" checksum table (which perhaps it hasn't done > in my case!) Ah I see. When even the checksum table itself is damaged, then gigdump will not print you the checksums of the individual samples at all. In that case you would need to check the samples manually first and then use gigdump --rebuild-checksums foo.gig to rebuild the entire checksum tale. CU Christian |
|
From: Jaime T <eno...@gm...> - 2017-11-03 13:34:42
|
On 3 November 2017 at 10:34, Christian Schoenebeck <sch...@li...> wrote: > In that case you would need to check the samples manually first and then use > gigdump --rebuild-checksums foo.gig > to rebuild the entire checksum tale. Ok. I'm not too sure exactly what I need to do to "check the samples manually" (the gigapiano, malmsjo grand and tascam rhodes instruments have always sounded ok to me when I have played them) so I've tried out the "rebuild checksums" operation: $ gigdump --rebuild-checksums gigapiano.gig Recalculating checksums of all samples ... OK WARNING: File structure change required, rebuilding entire file now ... DONE NOTE: Since the entire file was rebuilt, you may need to manually check all samples in this particular case now! $ Just to make sure that gigdump is now happy with the gig file structure, I've run the "verify" operation against the "newly-built" gigapiano: $ gigdump --verify gigapiano.gig Verifying sample checksum table ... OK Verifying samples ... 204 of 204 Samples DAMAGED: Damaged Sample 1) "021b" expectedCRC=ffffffff calculatedCRC=d510065f Damaged Sample 2) "026b" expectedCRC=ffffffff calculatedCRC=65ff15d7 Damaged Sample 3) "031" expectedCRC=ffffffff calculatedCRC=11c75bec Damaged Sample 4) "036b" expectedCRC=ffffffff calculatedCRC=257d468d Damaged Sample 5) "040b" expectedCRC=ffffffff calculatedCRC=860d3c20 ... (lines 6-200 removed from this email for the sake of brevity) ... Damaged Sample 201) "058v3ub" expectedCRC=ffffffff calculatedCRC=8ce5c64c Damaged Sample 202) "058v3db" expectedCRC=ffffffff calculatedCRC=2c60b335 Damaged Sample 203) "058" expectedCRC=ffffffff calculatedCRC=86cd6610 Damaged Sample 204) "058" expectedCRC=ffffffff calculatedCRC=f1ab313c I'll be the first to admit that I don't fully understand what is going on here, but I have a funny feeling that something isn't quite as it should be. Would there be any value in me trying the same operations with the Artvista Malmsjo Acoustic Grand and the Tascam BG (Biggagigga/Purgatory Creek) Rhodes gigs, or should I just log a bug? |
|
From: Christian S. <sch...@li...> - 2017-11-06 13:43:35
|
On Freitag, 3. November 2017 13:34:34 CET Jaime T wrote: > Damaged Sample 201) "058v3ub" expectedCRC=ffffffff calculatedCRC=8ce5c64c > Damaged Sample 202) "058v3db" expectedCRC=ffffffff calculatedCRC=2c60b335 > Damaged Sample 203) "058" expectedCRC=ffffffff calculatedCRC=86cd6610 > Damaged Sample 204) "058" expectedCRC=ffffffff calculatedCRC=f1ab313c > > I'll be the first to admit that I don't fully understand what is going > on here, but I have a funny feeling that something isn't quite as it > should be. Looks strange to me. First of all, check if you are really running gigdump with the latest version of lilbgig: gigdump -v which should look like this: gigdump revision 3330 using libgig 4.0.0.svn33 Because sometimes people still have an old version of libgig under i.e. /usr/local which might conflict with another installation directory. Then try to rebuild the checksum table a 2nd time. Because your output said that it needed to rebuild the file structure, which is not very common. So maybe after rebuilding the checksum the 2nd time it might work in your case. If not, then you might also try to open the file with gigedit and then use "Save as ..." and save it under a new file name. Make sure you are using the latest version of gigedit and libgig there as well (shown in gigedit's About box). > Would there be any value in me trying the same operations with the > Artvista Malmsjo Acoustic Grand and the Tascam BG > (Biggagigga/Purgatory Creek) Rhodes gigs, or should I just log a bug? Uhm, I think it would require you like 5 seconds to find that out. ;-) CU Christian |
Thanks for helping keep SourceForge clean.
X