sample end pointers bug

d/led Kontakt 1.5 today
aside from a fair number of crashes (OSX.3)
i'm getting lots of garbage at end of samples
(bits of sample data from the same sample set)
checked the same instruments on 1.2 on OS9
and they're fine - sounds like a bug
anyone else found this?

 

more info on this problem
1) 'garbage' at the end of samples is actually the start of the next sample file
2) only seems to apply to instruments
previously converted from giga format
on OS9 v1.2
3) problem samples look fine on loop editor window but auditioning still reveals sample end problem
am i really the only person experiencing this?

my next step is to reconvert one of the problem instruments in OSX.3

 

ok i think i can see what's happening now

this only seems to apply to giga conversions done on v1.2 (haven't checked v1.5 conversions on OSX.3)

problem samples are starting to play a loop
even with loop mode set to 'off'. just the first 100ms or so but enough to render instruments useless.

the problem may well be with 1.2 rather than 1.5

i never use loops otherwise it would have been more obvious

i must add that the giga conversion in 1.2 did always seem a bit hit and miss.

 

Hi,

did not experience your problem - just imported a gig into 1.5 (OSX) and playback does not have the glitches you discribe but seems pretty fine. (Does not say anything about the ability to convert complex Gig-files).

best,
Steff

 

...

hello

thanks for your response

i"ve just redone some giga conversions on 1.5 and you DEFINITELY have a
repeatable bug here. As i said on the forum i believe you have always
had
some problems in your giga conversion code. Often in my experience
double clicking on a .GIG file generates the error "this file is
corrupted or incomplete" - these are files that then can be installed
on a Gigasampler workstation and work perfectly.

The odd thing is that on 1.5 the problems are more obvious (whether the
conversion is done on 1.2 or 1.5). I never said that ALL giga files
generate this corruption, only some and not always the complex ones
either. The problems definitely seem to be in the loop data structure.

I am not in the business of beta testing but since i am currently
trying to move over to an OSX only music development environment and
Kontakt is central to that end i have a vested interest in getting this
sorted out.

May i suggest the following:

I try and reduce one of the affected files to the smallest possible
size i.e reduce it to one sample and email it to you. This of course
may not be possible in the sense that removing zones & groups may also
remove the problem. Please let me know if you want to do this as i"d
rather not waste my time if no-one is going to follow it up.

Incidentally you also have another repeatable problem regarding files
that work fine on 1.2 on OS9 but not on the new OSX version (Akai
conversions in this case). I can let you know about that some other
time. I"ve had quite a lot of crashes by the way. Kontakt"s the only
app that"s crashed Panther so far.


regards
Rod


On 7 Nov 2003, at 14:53, Native Instruments forum wrote:

 

Bug

I have the same problem with converted giga files. Running Mac OS10.8
and DP 4.11. Converted the giga files with 1.5. Seems that when I diable the DFD option and load sample into memory it goes away. It might have something to do with disk streaming and the giga conversion

 

Well,

ok, I loaded into RAM (because I first want to convert and save to disk then). OK, this was a 100MB gig only - will not work this way with a 3GB piano.

best,
Steff

 

...

interesting
do you mean that if you disable DFD - convert GIGA - save file -
renable DFD
then reload the file the corruption has disappeared. If so at least we
have a work around for the time being
.
On 7 Nov 2003, at 23:18, Native Instruments forum wrote:

 

Re: Bug

yes, of course, it is related to DFD. The spurious data is just the DFD buffer for that particular sample being spat out at the end. Nothing to do with looping at all. How stupid of me.

 

bug

Yes, that seems to be the problem. You must dissable DFD for all playback. I dicovered this problem with SAM HORNS using the Kontakt update they supplied for this library. I don't seem to have any problems with DFD if the sample is not a giga conversion.

The question is: Is this a problem with the new DFD software or is it the giga conversion process itself ?

Joe

 

my guess would be the conversion software

but you know what i still think it could be related to looping like i first suggested
i don't know if you've tried this but if you
move the loop start point of a problem sample
then this becomes the bit spat out at the end

it's as if the DFD is trying to deal with spurious loop data generated by a bug in the giga conversion code and emptying a buffer full of data before it realises it shouldn't looping

 

BUMP...

I was just bitten by this bug last night. Wonder if there is a solution yet? It's quite startling when I held a key for a while to hear the violin sample dying away, and then suddenly a loud burst of the violin for about 1/2 second!

This is on OS 10.2.6. Happen both in stand-alone mode and as VI in DP 4.11.

 

...

yep, that"s the one
we"ll have to wait for an update - that"s of course if they"ve even
taken any notice
of this thread

On 11 Nov 2003, at 23:18, Native Instruments forum wrote:

 

Not only giga

It happens to me with the included Yellow Tools patches as well.

And my own samples as well.

 

Work Around

If you set both buffers in the dfd settings to the minimum then it's gone.

 

Re: Work Around

Thanks, Chaim. It works. Now can someone explain why reduciing buffers helps?

 

hey, thanks for the tip - it does seem to work
i imagine setting buffers to such a small size must hit system resources pretty hard but i guess it's all we can do til they fix it

 

why does it work?
the extra bit of audio at the end of samples must be the contents of one of those buffers
and i guess you just don't notice 24k of audio

 

That makes sense. As I gradually reduced the buffers, the "unwanted" loop got shorter (and softer when buffers are very low.)