Little Lizard Piano
Moderators: MattKingUSA, khz
Little Lizard Piano
This was a lot of work.
The "Salamander Grand Piano" by Alexander Holm is one of the best free sampled pianos. But sampled at every third interval note, fully sustained, at 24 bit 48 KHz, with 16 dynamic layers of notes (plus release, resonance, and pedal samples), it's a 1.82 gig instrument. That can tax the RAM of many computers, especially if used in a mix with other instruments.
So, I set about to create a vastly smaller version, with hopefully little discernable difference in sonic quality. I call this version the "Little Lizard Piano".
The first task was to reduce each sample from 24 to 16 bit. 24 bit is great for recording. (The extra headroom avoids clipping). And you want to mix down in 24 bit, (even if using 16 bit sampled instruments). But for a single pitch, at 1 volume/dynamic level, of a solo instrument, 16 bit is plenty dynamic range (if you record at proper level). So, the instrument was significantly reduced with no discernible loss.
Secondly, the sample rate was reduced from 48 KHz to 44.1. Instruments with strong upper harmonics, such as cymbals, can suffer from such a conversion. But the rate conversion algorithms of today's audio editing software are very good, and Salamander went through the process well.
Third, I experimented with reducing the velocity layers from 16 to 7. Nearly all sample players scale velocity between layers anyway, so having 7 points along the log curve makes for a convincingly seamless dynamic range/response.
Finally, I employed some subtle, and hopefully unnoticeble sample looping. Certainly, in a mix or band setting, it should be undetectable.
The result is that the 1.82 gig salamander shrunk to a little 317 meg lizard. Hopefully, you'll find him to be a chameleon, aptly masquerading as his big brother. And you can easily use him in your mix.
http://www.bandshed.net/sounds/sfz/Litt ... dPiano.zip
The "Salamander Grand Piano" by Alexander Holm is one of the best free sampled pianos. But sampled at every third interval note, fully sustained, at 24 bit 48 KHz, with 16 dynamic layers of notes (plus release, resonance, and pedal samples), it's a 1.82 gig instrument. That can tax the RAM of many computers, especially if used in a mix with other instruments.
So, I set about to create a vastly smaller version, with hopefully little discernable difference in sonic quality. I call this version the "Little Lizard Piano".
The first task was to reduce each sample from 24 to 16 bit. 24 bit is great for recording. (The extra headroom avoids clipping). And you want to mix down in 24 bit, (even if using 16 bit sampled instruments). But for a single pitch, at 1 volume/dynamic level, of a solo instrument, 16 bit is plenty dynamic range (if you record at proper level). So, the instrument was significantly reduced with no discernible loss.
Secondly, the sample rate was reduced from 48 KHz to 44.1. Instruments with strong upper harmonics, such as cymbals, can suffer from such a conversion. But the rate conversion algorithms of today's audio editing software are very good, and Salamander went through the process well.
Third, I experimented with reducing the velocity layers from 16 to 7. Nearly all sample players scale velocity between layers anyway, so having 7 points along the log curve makes for a convincingly seamless dynamic range/response.
Finally, I employed some subtle, and hopefully unnoticeble sample looping. Certainly, in a mix or band setting, it should be undetectable.
The result is that the 1.82 gig salamander shrunk to a little 317 meg lizard. Hopefully, you'll find him to be a chameleon, aptly masquerading as his big brother. And you can easily use him in your mix.
http://www.bandshed.net/sounds/sfz/Litt ... dPiano.zip
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
- DoosC
- Established Member
- Posts: 268
- Joined: Tue Apr 20, 2010 8:28 pm
- Location: Saeul, Grand Duchy of Luxembourg
- Has thanked: 5 times
- Been thanked: 1 time
- Contact:
Re: Little Lizard Piano
Thank you VERY much !
It really seems to have been a lot of work but it is really worth it. I am probably not an audiophiles but the end result is GOOD !
Hats off to you
You really are the SFZ guy around here.
It is with the greatest pleasure that I honour you with the golden SFZ of eternal gratitude
It really seems to have been a lot of work but it is really worth it. I am probably not an audiophiles but the end result is GOOD !
Hats off to you
You really are the SFZ guy around here.
It is with the greatest pleasure that I honour you with the golden SFZ of eternal gratitude
| DoosC |
Re: Little Lizard Piano
Thanks for the many SFZs you have made which are a great contribution to linux audio.
I was curious about the difference in RAM memory usage between Lizard and Salamander so I did a test. Here is my method:
1. Load a sample in qsampler (Lizard or Salamander)
2. Play a midi file (some classical piano midi files from the International E-piano competition:http://www.piano-e-competition.com/midi_2011.asp). This is to provide some realistic range of notes that one might typically play. Also good listening. I use kmid to play midi files.
3. Check memory usage of linuxsampler with "top". Look at the VIRT column - sum of virtual+physical memory of the process. Play music for at least 10 minutes. Memory usage tends to rise over time, but levels off.
I know that linuxsampler only loads a fraction of samples at once, and then reads samples from disk as needed to minimize memory usage. I notice the memory usage increases slightly over time, I suppose because more samples are required as midi playback goes on (would depend on the midi file).
Here are my results:
kHz bit type VIRT RES SHR Disk
Salamander 48 24 wav 310m 309m 34m 1.8g
Lizard_88 44.1 16 wav 209m 208m 33m 319m
Salamander 48 24 flac 595m 593m 33m 704m
Lizard_88 44.1 16 flac 337m 274m 33m 63m
(sorry column titles are not properly aligned)
Lizard_88 = 88 key version of Lizard, the largest one
VIRT = total of virtual + physcial + swap memory
RES = total of physcial memory
SHR = shared memory
Disk = Disk size of samples.
This test seems to show that the actual RAM use between Salamander and Lizard is not all that different
(310 MB vs 209 MB) which is a bit surprising. I do not claim to understand this, and maybe my methodology is flawed, but perhaps it just means linuxsamplers memory cache method is just very efficient. Comments on my method are welcome, and perhaps I'm overlooking something.
You can also see I tested flac versions of the samples. I like flac because it really decreases the hard disk space and has no impact on CPU/DSP usage than I can see. However, curiously, the flac samples seem to require roughly twice the memory as wav samples. I can only guess that this has something to do with how linuxsampler caches the samples. I also notice that flac samples memory usage tended to increase more with time, whereas wave samples memory usage only increased slightly over time.
Perhaps my method is incorrect, but it would seem that unless you have really very little RAM, that there is not a big reason to use the Lizard version of Salamander.
I was curious about the difference in RAM memory usage between Lizard and Salamander so I did a test. Here is my method:
1. Load a sample in qsampler (Lizard or Salamander)
2. Play a midi file (some classical piano midi files from the International E-piano competition:http://www.piano-e-competition.com/midi_2011.asp). This is to provide some realistic range of notes that one might typically play. Also good listening. I use kmid to play midi files.
3. Check memory usage of linuxsampler with "top". Look at the VIRT column - sum of virtual+physical memory of the process. Play music for at least 10 minutes. Memory usage tends to rise over time, but levels off.
I know that linuxsampler only loads a fraction of samples at once, and then reads samples from disk as needed to minimize memory usage. I notice the memory usage increases slightly over time, I suppose because more samples are required as midi playback goes on (would depend on the midi file).
Here are my results:
kHz bit type VIRT RES SHR Disk
Salamander 48 24 wav 310m 309m 34m 1.8g
Lizard_88 44.1 16 wav 209m 208m 33m 319m
Salamander 48 24 flac 595m 593m 33m 704m
Lizard_88 44.1 16 flac 337m 274m 33m 63m
(sorry column titles are not properly aligned)
Lizard_88 = 88 key version of Lizard, the largest one
VIRT = total of virtual + physcial + swap memory
RES = total of physcial memory
SHR = shared memory
Disk = Disk size of samples.
This test seems to show that the actual RAM use between Salamander and Lizard is not all that different
(310 MB vs 209 MB) which is a bit surprising. I do not claim to understand this, and maybe my methodology is flawed, but perhaps it just means linuxsamplers memory cache method is just very efficient. Comments on my method are welcome, and perhaps I'm overlooking something.
You can also see I tested flac versions of the samples. I like flac because it really decreases the hard disk space and has no impact on CPU/DSP usage than I can see. However, curiously, the flac samples seem to require roughly twice the memory as wav samples. I can only guess that this has something to do with how linuxsampler caches the samples. I also notice that flac samples memory usage tended to increase more with time, whereas wave samples memory usage only increased slightly over time.
Perhaps my method is incorrect, but it would seem that unless you have really very little RAM, that there is not a big reason to use the Lizard version of Salamander.
Re: Little Lizard Piano
Do you have your audio out engine set to 48K 24 bit? I'm thinking maybe LS is converting lizard back to that format on load (especially if dealing with a compressed format like flac -- not useful unless you really have dIsk space problems).
While caching is quite useful for playing back pre-recorded tracks (that don't change in realtime), it's not practical for live use. And everything I do has an eye for live use since that's what I need. You need the entire sample set loaded for live use (or if doing realtime mix changes).
While caching is quite useful for playing back pre-recorded tracks (that don't change in realtime), it's not practical for live use. And everything I do has an eye for live use since that's what I need. You need the entire sample set loaded for live use (or if doing realtime mix changes).
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
Re: Little Lizard Piano
For these tests I am running Jack at 48kHz and I believe Jack uses 32 bit floating point for samples which I believe is what you might mean by audio engine. As far as linuxsampler is concerned I am using its defaults, and I'm not even aware what configuration options it has. Looking at what qsampler supports I see there are options for number of disk streams and voices (90 and 64 by default). I did the tests with Jack at 44.1 kHz, and also with the "force 16 bit" option (in qjackctl), but the memory usage was essenially unchanged.
I do not understand you statement: "While caching is quite useful for playing back pre-recorded tracks (that don't change in realtime), it's not practical for live use." First, of all the "caching" is part the design of linuxsampler, not under my control, and which is done for the express purpose of minimizing RAM use, and from what I can see it works well. In addition from the sampler's point of view it is just playing back a stream of midi events it does not matter if they come from a keyboard from a live player or by playing back a midi file previously recorded by a live player (which is what I am using for this test).
Anyway, you do a great job putting together SFZ files many of which I use and enjoy so I very much appreciate your work. My point here, is just that as far as I can tell, the size of the samples does not seem to affect RAM use as much as one might expect. It may be that my test is not correct, and if you can suggest a better way to measure memory use please pass it on.
I do not understand you statement: "While caching is quite useful for playing back pre-recorded tracks (that don't change in realtime), it's not practical for live use." First, of all the "caching" is part the design of linuxsampler, not under my control, and which is done for the express purpose of minimizing RAM use, and from what I can see it works well. In addition from the sampler's point of view it is just playing back a stream of midi events it does not matter if they come from a keyboard from a live player or by playing back a midi file previously recorded by a live player (which is what I am using for this test).
Anyway, you do a great job putting together SFZ files many of which I use and enjoy so I very much appreciate your work. My point here, is just that as far as I can tell, the size of the samples does not seem to affect RAM use as much as one might expect. It may be that my test is not correct, and if you can suggest a better way to measure memory use please pass it on.
Re: Little Lizard Piano
I haven't looked at the LS sources, so I don't know its scheme for caching. But without knowledge of what specific samples need to be preloaded, disk caching always runs the risk of not being able to get a certain sample loaded fast enough for playback. It's a gamble. You need to disable that if you want your software sampler to be as reliable as a hardware unit.varpa wrote:I do not understand you statement: "While caching is quite useful for playing back pre-recorded tracks (that don't change in realtime), it's not practical for live use."
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
Re: Little Lizard Piano
I also play live keyboards using midi keyboard and samples using numerous linuxsampler channels and have never had a problem with linuxsampler choking up and failing to be able play notes (this is playing with latency of 4 ms roundtrip - see http://www.remastersys.com/forums/index ... pic=3300.0 for a description of my setup). So I don't think there is any problem with caching in linuxsampler. From what I understand, from a historical perspective sound font players did not do caching but loaded the entire samples which can become problematic with large samples. Then Gigisampler was developed with an caching scheme so that the entire sample did not need to be loaded at once which was a great innovation. Later on linuxsampler was developed and also implemented a caching scheme since this is the only way to handle very large sample sets. Certainly, if you are running on limited hardware, like a netbook with 1 GB of RAM then keeping your samples size to a minimum would be important, but otherwise I cannot see that you have to worry so much about sample size.
What set up are you using? Have you had problems using the full sized Salamander Piano sample set? What happens? Notes stutter because the sampler cannot keep up? Xruns?
What set up are you using? Have you had problems using the full sized Salamander Piano sample set? What happens? Notes stutter because the sampler cannot keep up? Xruns?
-
- Posts: 1
- Joined: Thu Nov 24, 2016 12:15 am
Re: Little Lizard Piano
Hi there! I know I'm two years late to the party, but I stumbled onto this post while looking for good piano samples, and I really like what I've been reading here.
I'd very much like to try out "Little Lizard", but it looks like the download link's dead... Is it still available for download anywhere? I'd really like to give it a try!
Thank you for the hard work!
I'd very much like to try out "Little Lizard", but it looks like the download link's dead... Is it still available for download anywhere? I'd really like to give it a try!
Thank you for the hard work!