I hadn’t seen this thread before, but it’s super interesting. It’s fun to dig into the Octachainer code.
I think this is how the position is calculated: https://github.com/KaiDrange/OctaChainer/blob/master/otwriter.cpp#L25
Without seeing your script, just a shot in the dark… Could the issue be endianness? That bswap32 function reverses bytes for big/little endian:
i’ll try to organize my script and share it here
I have A Renoise Lua script tool that slices samples and creates .ot files. Unfortunately I am also not calculating the trim and loop stuff properly, so when I import a sample to the OT I also get that error. I would love to see how you resolve the issue.
Okay maybe I should start by actually trying to describe what I want to achieve.
I’m preparing a pseudo-DJ set. I split my songs into 2 parts in Ableton Live to be super precise. First wav file most of the track and second file is usually a last part that can loop forever until i prepare a second track etc. Then using DigiChain I create a 2 slice sample chain out of these 2 files. I’m going through all this hassle to be super precise to the songs are always “on the beat”.
Essentially a higher level of what I wanto to achieve is this: song starts to play, plays until the end and loops the last section i chose earlier “forever”.
Anyways, Obviously this way I was sacrificing 2 patterns, 1 for the main part and 2 for the “looped” last part of the track. Later I thought instead of using “slices” if I can precisely set the loop point of the audio, I can do the same with just 1 pattern.
So with a bash script I wrote (with great help from ChatGPT ofc) right now I grab the 2nd slice’s start point from the HEX dump of the ot file Digichain generated, and overwrite “loop start” with that value. This seems to work for the most part. When I load the associated wave to a static track slot, the file is loaded but I see an error dialog saying “sample load error!”. But when I check the audio file in AED, i can see i successfully set the loop start and everything normally works.
What I recognized later is: Octatrack seems to “fix” the attributes by itself. Because when I “save file attributes” on octatrack and compare the resulting ot file’s hex with “unmodified” ot file’s hex I realized Octatrack did some changes to “fix” the file. One of those changes is setting Loop to 0000 0001 (essentially loop “on”) and I feel like there’s smt like if loopStart != 0, then loop is true going on. and it also changes the “loop length”, because obviously, the length of the loops changes (assuming by default loop start = trim start, loop length = trim length).
so again, assuming my checksum calculation is correct, i think Octatrack is complaining because the “attributes” of the file does not match the other metadata (in this case, the “changed” loop start) initially when the file is loaded into a slot.
initially i assumed loop length should be in samples and i tried calculating loop length by subtracting slice 2 start point from slice 2 end point, but octatrack complained again AND changed loop length bytes after it “fixed” it. that’s why i think loop length is actually written in “bars”. OR maybe i didn’t to the byte inversion?
anyways, here’s my code (unfortunately an earlier version where I don’t have the loop length calculation, because the other file i’m working on got super messed up trying to calculate it in bars etc, it’s a big mess lol):
later i’ll try to post a more up-to-date version that has looplength calculation in samples if i’m able to clean up the other messy code (or maybe even start from scratch)
omfg after 3 days of fiddling finally found the solution!
i found out the second 4 bytes of a slice is actually the “slice length”, not the slice “end point”.
so essentially i took advice of @sezare56 and assumed looplength should be in samples.
to be able to store the correct “loop length” i had to overwrite it with the slice “length”, since i was already setting loop start to slice start. (previously i was trying to sutract start start from the supposedly slice end, which was actually the slice length!)
remember my actual goal was to have the very end of the file (slice 2) as the “loop” that will go on forever after the whole file is played through?
after this i realized another mistake was not reversing byte order for the checksum after calculation.
after i handled these two, i was able to import to file to a static slot without any errors!
this is the fixed bash script if anyone’s interested:
some bits that are not directly related to the problem i was having and its solution:
currently it clones the original ot file, adds “_loop” at the end of the filename and do modifications. i was originally planning to clone the associated wav file and add “_loop” at the end too but it’s not ideal since 1) i’ll be doubling the size occupied in the cfcard (which is a minor problem since this card is dedicated to this dj set only) and 2) i’ll have double the amount of audio files listed in OT file browser (major problem for me). so i think i’ll either do a manual backup of my AUDIO folder for now, or just include further logic that creates backups for the original ot files with an extension like “.bak” and modify the original file. i think i can also include a new argument like “restore” to restore “.bak” back into the original ot file again.
maybe it’s a good time to put this into a github repo now since now i have the basic functionality that i need, and i’d love to have version control from this point on 
You can make it with 2 slices.
that was what i did before. but a slice means a trigger, a trigger mean i’ll need to sacrifice +1 pattern to do this.
now i can have 1 song per pattern because i only need 1 trigger to start playing the song and it will play from start to the very end, then loop from my chosen loop point (let’s say the “last drop”) forever
If I remember correctly I found a way to automatically play the 2nd slice after 1st one.
Can’t check now, but it is in with LEN=SLICE mode, LEN=2, Loop on. Only 2nd slice is played.
Can’t remember the caveats, it was for playing a looped sample (slice 2) with a different attack (slice 1).
hmm that sounds interesting, i’ll give it a try.
omg yes this indeed works! hahah! i feel so stupid now 
frankly i didn’t even remember we had the possibility to set “length” when we use slices 
looks like me trying to achieve the exact same thing in a super hacky way by hex editing the ot file was quite meaningless
anyways, i can comfort myself thinking at least this was a good practice to level up my bash scripting game and being more familiar with the ot file structure 
hopefully the (sort of re-evaluated) findings regarding the ot file structure can come in handy for someone else for some other task, because afaik there are multiple examples of “creating the ot file from scratch”, but i haven’t seen anyone trying to “edit” an already existing ot file.
Don’t. I’m so clever. 
I can’t remember why I’d still need some script to edit slices for the attack/loop purpose…
anyways, if “for some reason” anyone needs my script (even just to take a peek at stuff like how checksum is calculated and byte reversed etc, or how can you “get” slice start and length of a particular slice from the hex dump of an ot file) it’s living in a github repo now.
I’d be interested for the attack/loop samples purpose, with a loop point instead of 2 slices, so that it would be played normally in slice mode.
I was thinking of something like odd imported samples are the beginning of the slice, the even the looped part. The goal being to have 64 slices with loop points, from 128 samples or less
I’ve updated DigiChain to set the tempo, trim length, loop length, loop, and loop start values correctly when generating the .ot files, no errors loading into my Octatrack with these files 
Brian you’re the man! I can’t describe the help you’ve (perhaps unknowingly) provided to me in 2023. My DT, OT and M8 productiveness is off the roof thanks to you!