linuxsampler-devel

[Linuxsampler-devel] akaiextract loop start <-> loop end

[Kolja K. <ko...@fr...>]

Hi,
while working with some wav-files extracted by akaiextract, I noticed that the information for loop-start and loop-end stored in the sfinst of the wav-files seem to be in swapped order.
Example:

MIDIUnityNote: 41
Channels: 1
SamplesPerSecond: 44100
BitDepth: 16
FrameSize: 2
Frames: 176565
MIDIUnityNote: 41
FineTune: 0
Loops: yes
LoopType: 0
LoopStart: 175036
LoopEnd: 113915
LoopPlayCount: 0
LoopSize: -61120

LoopStart is higher then LoopEnd, thus LoopSize is calculated wrong.

I didn't see this in any other looped sample I worked with yet (e.g. when extracted from a working gig-file using gigextract).

Has anyone else seen this?

When swapping those numbers, the loop plays, though glitches appear.

Cheers,
Kolja

Re: [Linuxsampler-devel] akaiextract loop start <-> loop end

[Christian S. <sch...@li...>]

On Montag, 15. November 2021 15:46:27 CET Kolja Koch wrote:
> Hi,
> while working with some wav-files extracted by akaiextract, I noticed that
> the information for loop-start and loop-end stored in the sfinst of the
> wav-files seem to be in swapped order. Example:
> 
> MIDIUnityNote: 41
> Channels: 1
> SamplesPerSecond: 44100
> BitDepth: 16
> FrameSize: 2
> Frames: 176565
> MIDIUnityNote: 41
> FineTune: 0
> Loops: yes
> LoopType: 0
> LoopStart: 175036
> LoopEnd: 113915
> LoopPlayCount: 0
> LoopSize: -61120
> 
> LoopStart is higher then LoopEnd, thus LoopSize is calculated wrong.

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?

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.

[1] https://en.wikipedia.org/wiki/Data_degradation

> I didn't see this in any other looped sample I worked with yet (e.g. when
> extracted from a working gig-file using gigextract).
> 
> Has anyone else seen this?
> 
> When swapping those numbers, the loop plays, though glitches appear.

Usually you can simply open the wave in a sample editor and literally see 
where the loop points are, especially with such small samples as in the Akai 
format.

CU
Christian

Re: [Linuxsampler-devel] akaiextract loop start <-> loop end

[Kolja K. <ko...@fr...>]

> 
> 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.

Since I don't own any other means of testing the AKAI-image, I cannot tell, how they would 'originally' sound when looped.

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.
I don't know the details of how the data is stored in that filesystem but 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.

> 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

Re: [Linuxsampler-devel] akaiextract loop start <-> loop end

[Christian S. <sch...@li...>]

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