WAV files are slightly too long when put in DAW

@BrennanSingularSound: This needs highlighting. I think @Quad is right here, if you’re going to have these seam samples, add them in separate files. There’s negligible cost in terms of space, and it’s far more intuitive ready for the day when the content of the SD card becomes more user editable (backing tracks, longer user content, etc). You don’t want to get into the future problem of having user loaded wav files be the wrong length because you’re subtracting 360 samples from them. Make this change internally now while there is no confusion.


Yes this is tedious. I don’t know where to begin beyond just tracking aeros into ableton instead of this trimming. How do I trim correctly in ableton? Anyone know? Seems simple enough for Singular Sound to make a quick support video showing the process at least.

1 Like

Here’s a batch conversion method to fix this issue: [HOW TO] Trimming 360 samples from your tracks

Look I’m loving the Aeros and am hopeful to see it come more fully into fruition. That said, could this at least get tagged as possibly something to address in future updates? I appreciate desolationjones’ attempts to find a work around but a simple import to daw should be the ideal standard for the Aeros.

Yes, I’ve had to stop using Aeros, and now just use an 8 track MP3 recorder. Then I create loops in a DAW.

An idea occurred to me to pass on to the devs.

The extra 360 samples shouldn’t be added to the end of the loop file or in a separate file. These wavs are loops… They should be mixed and added to the first 360 samples of the loop file (if at all). You can hard wire the fade out when you add them. That would remove any click from a non zero sample at the loop point.

Cross fades when you’re changing loop file then fade the samples from the front of the previous loop into the beginning of the new loop.

No need for seam file, and no need for confusing extra samples at the end of the stored wavs.

If it were me implementing it, and bearing in mind that the wav should be getting streamed live to SD card not to memory, it would mean rewriting the front of the wav file on loop close. But I don’t think it’s a huge ask for a decently specced SD card. And probably, if you’re using Linux underneath as the operating system (I guess you are given the boot time and limited resources for becoming driver developers for a custom OS) it would take care of you if you simply mmap the loop file anyway. Linux will flush the changes to SD as time slicing allows. If you’re running 32 bit Linux you’d be limited to 2G of wav, but that’s probably okay in this application (and it’s a lot more than the 2.5 minutes you’re currently limiting to).

1 Like

Philosophically opposed to a looper modifying the raw data in the loop file. It’s a slippery slope.

For example, what happens when Aeros (or your daw) has a better way to make the loop seamless. If you’ve modified the only copy of the source material, you are stuck with that forever. It’s bad design.


That’s a reasonable argument. I don’t feel strongly enough that I’d really mind a separate file.

However, my counter is that a loop file is not the same as a normal recording. It should be viewed as a slice from an infinitely repeating signal. The best approximation of this is when we play through the phrase three times and record the middle one. So the beginning of the recorded loop contains the join from the end of the first loop (best example would be the reverb trails) and the end of the recorded loop includes the anticipatory playing for the start of the third repeat (for example, finger slide noise positioning ready for chord 1 again). Another way of thinking about it is that someone magically recorded an empty wav of exactly the right length and our first recording was done as an overdub… It has no beginning or end because you could have started the overdub anywhere. I think this is the purest form of a loop and it’s not the same as hard cutting a phrase.

Obviously we don’t want to have to play three times to create a looped phrase, so what can we do instead? Well we can do the overlap mix I described to make the loop closer to what it would have been had we recorded the second of three.

I find that nicer as a model of looping personally. But I’m not wedded to it. The ultimate solution is probably a separate file because everyone could get what they want with that mechanism. I think you and I would certainly agree that storing the seam samples in the file is very poor UX. Think of the poor techno luddite who just wants to copy a backing track onto aeros. They can just about cope with drag and drop to an SD card. Making them do sample level editing of their track first is madness. (And similarly for copying off of course)

I agree that the original signal should not be modified. The loop tail/head transition should be handled in hardware. Boomerang uses an (optional) fast, slight fade out/in. I have never had an issue with that, and I like being able to turn it off if I want to. How do other loopers handle “crossfading” between end and beginning of loop?

You only have to repeat the end, and fade it into the beginning, you don’t need to store it at all. The problem seem to arise from this auto-save feature.

That’s not true. You’ve got to have samples available from outside the loop time otherwise the cross fade would make volume change at the end of the loop or would have clicks when you cut the sample at an inopportune sample value (which is why singular added these seam samples in the first place).

Cross fade by definition takes the volume of one down while bringing volume of another up in counterpoint. There has to be overlap. For a loop sample that means you need more samples than the length of the loop available.

Not trying to hijack this thread, but does anyone use Studio One as their DAW and can explain how to remove specifically 360 samples/frames from an imported Aeros loop file, other than manually trying to trim it and guess on how many samples are being removed?

The loops are in memory though, you don’t need a physical loop for it to work. I’m a programmer. There’s no difference between a physical loop, and a loop in memory. In fact it should work better, because its faster than saving them.

1 Like

Someone posted a batch file that will do all of them for you in one go.

They are at present stored in memory for playback, but a large part of this thread is about how they are stored on SD card when saved. Also remember that singular are currently working on changing from streaming from ram to streaming from SD card, so this becomes even more relevant.

Yes, and I’m saying… “why are they doing that?” It’s worse. Computers have been used since 1980 without saving everything… why would this be better?

1 Like

Never mind. I just imported a few wav file loops from different parts of a song I made in my Aeros directly into Studio One, moved them around, added a drum track, and without trimming anything, they worked perfectly. So at least for S1 (and me), no trimming of the loops was necessary. Unless I’m not doing what other folks are that requires the 360 sample trimming.

1 Like

You’re a programmer.

Do a quick calculation on the memory requirements for six stereo 24 bit, 44kHz audio streams.

I think you’ll answer your own question.

They work on my computer without the samples being saved with bits on them.

That would be great, but I’m not sure that’s what they are working on. They may just be making the time limit be bigger (and not as big as you have sdcard space) or let any track use as much of the remaining preallocated buffer.