Quick Sign In:  

Forum: VirtualDJ Technical Support

Topic: Possible bug with vdjsamples

Dieses Thema ist veraltet und kann veraltete oder falsche Informationen enthalten.

It appears to be a bug with vdjsamples when adjusting anything related to key (i.e. key itself, key apply mode).

When doing so the source path is moved to end of file, the original location in the file (0x78) is overwritten with 0x00 (the path length at offset 0x60 is still present). It seem as the thumb and path chunks are mixed up.

However, if an actual thumb is added to the file after this change, the path disappear completely, also from the end which seem to confirm the mixup.

A healthy sample file with path intact created by dropping the audio file into the sample side panel:



After changing the key mode (or setting/scanning for a key) - the path is now nulled, the length of the path area is even extended to some apparent arbitrary length, and path now exist at the end (where the thumb normally would be - in this case there is no thumb yet, see below):



I actually had to "reset" key (remove key and set it back to default mode) to be able to add a thumb as it refused to save the thumb otherwise.

What happens now is that the the path is removed completely and we see the end of the PNG IEND chunk (or last part of the PNG thumb) instead where the path was (seem to be offset/pointer assuming path is found at the same location as the thumb):



Also, in VDJ we'll now see the PNG IHDR chunk represents the path confirming this:


 

geposted Tue 07 Jan 20 @ 1:18 am
Related is for example Audio+Video samples where anything key related is changed.

Take the included sample as the Ahhh - Scratch.vdjsample:



Then change something with key:



The sample is now mangled, data gone in display (but exists in the file) and cannot be played:



The only change seem to be related to transparency color(s) (?) and something early in the header. The "key" area (?) (0x70 - also see offset stored at 0x08) seem wiped as well. Diff between the mangled and original files:


 

geposted Tue 07 Jan 20 @ 1:27 am
Ref. first post: Just noted - it seem to mix up the offsets that exists at 0x54 (Uint32 for thumb) and 0x5C (Uint32 for path). Hope this helps tracking down the bug.

In this image they are also the same pointing to the same data:

 

geposted Tue 07 Jan 20 @ 3:27 am
AdionPRO InfinityCTOMember since 2006
Confirmed the bug with not being able to store thumbnails on older vdj samples and the source path being overwritten.

I didn't manage to corrupt the original Ahh Scratch sample in the way you described though.
 

geposted Tue 07 Jan 20 @ 11:46 am
Not sure why it couldn't be reproduced. I made a short screen cast showing the steps below - it's essentially open the editor, set some key flags, save and boff :).

The system is Win 10-64, VDJ v.8.4-64 b5402 (I can't remember if this happened in earlier versions).

 

geposted Tue 07 Jan 20 @ 12:40 pm
Adion wrote :
Confirmed the bug with [...] older vdj samples
Just wanted to mention that this happens with fresh new samples in my case - all the sample examples above were made the last couple of days from scratch with new sources (except from the ahhh - scratch which was downloaded/updated yesterday). Seem as the version number in the sample is 8.31 (assuming this is what is represented at 0x04?). Not sure what the newest should be, but I'm unable to create anything newer in my version of VDJ. Hope this helps.
 

geposted Tue 07 Jan 20 @ 1:41 pm


(Alte Themen und Foren werden automatisch geschlossen)