On Dienstag, 16. November 2021 19:38:44 CET Kolja Koch wrote: > > Looks like data corruption to me. Akai sounds are decades old. On what > > medium did you have that Akai sound stored on; HD, burned vs. pressed > > CDROM? > The sounds come from an AKAI-image with looped brass-sounds. I don't really > use these, just for testing purpose. It took me a while to see that the > issues I had were not in my gig-creation, but in those wav-files instead... > I managed to use some other wav-files containing loop information, those > work as expected.
In all these years there were only a hand full of people that still wanted to access their old Akai sounds, because you would barely find a sound library in Akai format that would sound good enough even for standards 20 years ago. I also still own numerous Akai CDs and Akai hardware sampler, but I haven't touched them in years. I once had plans to add support for S5000/S6000 format as well, but figured who would need that apart from nostalgic look backs. > Since I don't own any other means of testing the AKAI-image, I cannot tell, > how they would 'originally' sound when looped. Like I said: you can visually see where the loop points are supposed to be, without even listening to them. When you open the wave in a wave editor you should easily be able to see two sections in the wave form that look identical. Exceptions are typically synthetic sounds, e.g. sampled FM synths, as well as a bunch of thin analague synth sounds which have an almost static wave form throughout the entire sample, but natural sounds (like your brass sounds) typically have a high variance in their wave form, so those almost identical two loop sections of the two loop points visually pop out. > Data corruption could theoretically be, though I didn't notice any other > problems with those files, only loop-start and -end and, consistent for > all files I tested, those values would, theoretically, make sense when > swapped. Bit rot are very seldom bit flips that appear over years. It is not like that you would have several bit flips in a row or somewhere nearby. The next bit flip is usually various MBs or even GBs away. So data degradation in general is a very subtle and slow phenomenon, especially on uncompressed data like this one. At most you might hear a pop sound somewhere in any of the samples. I encountered corrupt samples with such pop symptoms numerous times in the past, but it took me a while to actually realize, i.e. hear those issues back then. So there were good reasons why I revived the CRC32 checksum feature in the gig format and our tools, as it is not realistic to (re)verify sound libs by ears. These features will be extended in Gigedit was well. > I don't know the details of how the data is stored in that filesystem but Well, you know on which medium you have stored them on. I bet you have stored them as Akai image files on some ancient mechanical HD, which in turn would certainly have an ancient Linux or Windows file system, i.e. without self- healing features. If you even have it stored on a native Akai HD, same thing: all their filesystems were way more primitive. No self-healing. > would assume it to be a very specific data corruption. Anyway, as I said, > besides for testing my software I don't use these files, so that would have > been more of an academic interest to me. Exactly, same applies to all Akai owners I guess. :) > > In general I highly recommend to use a modern filesystem (e.g. btrfs, ZFS) > > nowadays with appropriate self-healing feature to prevent things like bit > > rotting [1], especially for long-term storage. > > Thanks for the advice, I will definitely keep that in mind! > > > Cheers, > Kolja CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
