When feeding a sample to a couple of slots on the CMI V and the sample rate of those samples is not particularly supported by the current system audio it seems the sampler just gives it up and locks up.

Would appreciate if someone could confirm -

1. get a few real FairLight CMX II or III samples that are sampled at 30,200hz, 8 bit, mono (or just get a few of your one shots you have laying around and make some copies of them at a sample rate that your system audio doesn't support directly.) Just take a look at the pull down sample rate menu in your audio system driver panel and pick a rate that is in between two settings.
Here is a database of original Fairlight CMX audio http://www.nattvard.com/iix/database.php

2. start loading up sound slots in a blank template (default) with these odd ball samples.
3. keep playing them while loading in more slots and see how long it takes before it locks up to the point you have to task-man it off...

I found neither the standalone nor the VST plugin would standup for very long without tanking itself. I ended up resampling these original FairLight files to 32Khz, 8bit mono and they all work fine with the CMI V. 32k is a rate supported by the RME system card. The CMI V is supposed to be able to handle original FairLight CMX II & III .VC and .CO files but it seems there are caveats...

 

Last edited: May 18, 2023

did you try the onboard audio driver (just to check)?

 

Oddly enough the system audio was slightly more tolerant but the end result was the same. Keep in mind this isn't an audio driver/system issue this is seemingly a software issue wherein no action was programmed into the CMI V to account for this particular scenario. The fact that arturia is marketing this tool as one that will import and utilize original extracted .VC files from genuine Fairlight storage medium (i.e. floppy disk) should indicate a better and more tolerant mechanism for dealing with such files. The methods that exist for extracting the samples from the floppies is quite varied and no standard exists in the way these samples are presented in databases. Ideally the samples should be extracted and presented with the same parameters that they were when they were put on the storage medium. However those who would use these samples are really at the mercy of those who are in possession of the original Fairlight disks. Those disks are few and far between anymore and the integrity of the data is getting dicier and dicier with each passing year. Lets face it, the only reason anyone would buy such an item would be to utilize native FairLight samples. At least, that is the only reason I have it.

 

Did you contact arturia? this sounds like an interesting problem to solve.
describe it like you did here and send the/one file.

even if you are "demoing" the synth

 

That was the plan originally - which is why I was itching to see if anyone else could duplicate it on their system

 

So no one here runs CMI V?

 

Not really, they all seem somewhat like experimenting/trouble. Have you tried the files you are testing with in any other emus like UVI Darklight or QasarBeach (https://adamstrange.itch.io/qasarbeach); to see if maybe it is just an Arturia or file-related problem? The link you included provides converted output file formats, and could maybe cause issues?

This is some QasarBeach release notes/fixes about trouble reading the IIx files, also.

• Reading IIx .VC with embedded .CO data better reading compatibility
• Reading IIx .IN will also load embedded .CO from linked .VC

Here are some other images and an extractor utility which may? be useful for use with IIx files.

http://zine.r-massive.com/fairlight-cmi-iix-archive/

 

Last edited: May 20, 2023

My CMI V loads those http://www.nattvard.com/iix/database.php original sample disk samples without any problem tried several of them

 

Yes - this was the source of the 30.2khz 8bit mono wav files. Which is what was originally loaded into CMI V and caused the app to lockup. Probably due to the fact that it couldn't handle the sample rate.

Just as a FYI the .VC samples extracted from those archives are hit and miss for the control files ( .CO) or control data of the originals that told the sampler what the loop points were, sample duration, fade out, etc...

 

Just for grins - what were the sample rates of the files you tried ? Were they .VC's or .WAV's?
Load up some of these attached .VC files in CMI V and see what shakes.

AS well try some of the 30.2khz wavs - they are extractions from the .VC's that came from the same batch. When you load them to a slot try changing to a different sample on that same slot on the fly without resetting.

(if ZIP doesn't work try RAR - had to rename the RAR files to zip on the fly becasue this forum apparently doesn't like RAR)

 

Last edited: May 20, 2023

tried .VC and .WAV
Audition shows 14080Hz 8 bit, mono
CMI V loads all as 33488

your files without problem too, except the KICK11.VC
it freezies the CMI V
I guess it's some buggy disk file looked inside it's empty

 

I assume you were referring to the .WAV's as 14.08khz? I used wavelab to re-sample some of them and all were originally clocked @30.2khz. I threw some of these into audition, and wavelab and also checked with MediaInfo as well on the production box and they all report 30.2khz 8bit mono. Not certain where the 14080hz figure came from...

 

So I went back to the r-massive site and re-converted the entire CMI IIx library. Which is where these test samples I uploaded came from. These new .VC test samples DID load in my CMI V as well @33.488khz. Tested slot loading over the top of previous files (without resetting slot) and that went without a hitch. Loaded samples to every slot and switched between slots/loading and playing that went OK as well...

KICK11.VC must be inherently corrupt off the original media as it locked up the app the same way. I replaced the old library files with new ones converted today and for the most part they load fine. There are others in the lot like the KICK11.VC file that will lockup the CMI V. They aren't 0 byte files but they apparently lack audio data. Either the conversion process is flaky or the original files got corrupted getting them off the original floppies.

Still, it would seem that if trying to load a file that is "not right" that the app should have the capability of handling that scenario a bit more elegantly than locking up the entire sampler.

 

If remember correctly CMI had the variable sample rate with 2,100 Hz - 30,2 kHz and any voice card could have it's own, the limit was the size of sample could be only 16kb
So the original sample library could be anything between