Crash loading SFZ exported with discoDSP Bliss

• 1 0

  Message de George le …
  Loading a SFZ file exported with our Bliss samplers crashes the app instantly. I have no idea what's the problem since SFZ and WAV files were created using standard formats. Find some example files to reproduce the issue attached.
  
  Best regards,
  George Reales
  https://www.discodsp.com/
  BrassMuteC12.zip
• ZI 190 0

  Message de ziyametedemircan le …
  The samples you can load into a soundfont can only be 16 or 24 bit.
  The problem occurs because your samples are 32 bits.
  You need to convert them to at least 24bit.
  
  PS: I converted one of the files you attached.
  BrassMuteC12-24-z01.zip
• 4 0

  Message de Mao le …
  ziyametedemircan, le … - Voir le message cité

  The samples you can load into a soundfont can only be 16 or 24 bit.
  The problem occurs because your samples are 32 bits.
  You need to convert them to at least 24bit.
  
  PS: I converted one of the files you attached.
  Zi - This is interesting because, loading the original files into Wavosaur, they read - in the interface - to be 16 and 24 bit. May I ask what program you used to verify the bit depth? Also, whatever program it was, it did not maintain the embedded loop points but of course, that doesn't matter for solving the question at hand... Thanks.
• ZI 190 0

  Message de ziyametedemircan le …
  Audacity
• 4 0

  Message de Mao le …
  ziyametedemircan, le … - Voir le message cité

  Audacity
  Appreciate you helping out on this... but I'm still not sure that's the problem.
  Audacity is a 32 bit floating point application. Every file loaded into Audacity shows 32 bit in the info next to the track.
  Is that what you are referring to? Because I see the same thing with the tracks you saved in Audacity and shared.
  I really believe there is a minor meta or header information glitch that's causing the problem and Polyphone is a tad sensitive about it.
  Not saying it's Polyphone's responsibility or fault... just saying that's what it looks like. I'm just trying to solve this... Thanks.
• BO 284 13

  Message de bottrop le …
  in Soundforge i see 16 and 24 bit files too, no 32 bit.
  
  in Polyphone the SFZs are imported without any problem.
  i still use Polyphone 1.9 though
  https://drive.google.com/drive/folders/1…yOn2R8KL?usp=sharing 
  
  regards bottrop
• ZI 190 0

  Message de ziyametedemircan le …
  I don't know. Perhaps Audacity is guessing wrong.
  I opened both files (the original you added, and the one I saved after the bit change) from disk and it looks like this:
  
  
  Also, the size of the saved ones is smaller than before.
  This shows that a change has been made.
  I don't know where the problem is, but the files I converted with Audacity can be opened in Polyphone 2.2.
• Message de ziyametedemircan le …
  I actually hoped Polyphone could do this format conversion silently. Because the software already has the necessary library to do this.
  Mr. Bottrop says that Polyphone software version 1.9 is able to open these files (I haven't tested it). So there may be a bug in 2.x version that prevents this format conversion.
• 4 0

  Message de Mao le …
  Looking at the hex code of the original files at
  https://hexed.it/
  and comparing to the spec at
  http://soundfile.sapp.org/doc/WaveFormat/
  and
  http://soundfile.sapp.org/doc/WaveFormat/
  the files are indeed 16bit and 24 bit. I believe the problem lies elsewhere, IMHO.
  Unless they are marked in the header 16 and 24 but encoded 32 ? Getting beyond my paygrade here.
  They load fine in other applications, so.... I dunno.
• 421 0

  Message de Davy le …
  When analyzing the wav files mentioned in this thread, I discovered that the sections "inst" have a length of 7 bytes but then everything was shifted. I searched why and here is a subtlety of the WAV files I wasn't aware of:
  
  https://sites.google.com/site/musicgapi/…ents/wav-file-format 
  One tricky thing about RIFF file chunks is that they must be word aligned. This means that their total size must be a multiple of 2 bytes (ie. 2, 4, 6, 8, and so on). If a chunk contains an odd number of data bytes, causing it not to be word aligned, an extra padding byte with a value of zero must follow the last data byte. This extra padding byte is not counted in the chunk size, therefor a program must always word align a chunk headers size value in order to calculate the offset of the following chunk.
  
  Next version of Polyphone will include this fix.

Connectez-vous ou inscrivez-vous pour participer à la discussion.