Ability to export and import tracks as WAV files is old news with loopers and other devices.
I’ve been doing it for years with Digitech Loopers and Touchmix Mixer.
So are y’all working on an export and import feature? Even if it’s just a simple program like the Touchmix - each channel as a WAV file in and out as is so we can edit them in a DAW.
Exporting is easy. Your DAW will open the wav files that you can simply copy from the SD card.
Importing is not easy. There’s extra information in the wav files and if it’s not there aeros won’t recognise any wav files you copy to the SD card.
Frustratingly, singular won’t say what that information is. I’m very tempted to just dissect one of their files and write a tool myself, but I don’t really feel like supporting them when they won’t give out the needed detail.
@kingofthejaffacakes if you have the knowledge and time I would welcome your efforts. How much would you charge?
QSC Touchmix mixers have a USB port where one can plug in a very high speed SSD drive and record any or ALL tracks to the external drive.
QSC wrote a program for the Touchmix Mixer Series that runs on the computer and merely:
Since the files as recorded on the SSD drive contain other information for the mixer, they cannot be edited directly from the SSD Drive plugged into a computer without screwing them up when re-written… Therefore the program imports and converts each selected recorded channel into the computer from the super high speed SSD drive as standard Wave File(s). These files can then be edited in a DAW such as Cubase.
Then one can import the/a set of wave files back onto the SSD drive as a NEW SONG and then one can play them back and record additional tracks on the Mixer. In other words, the program restores the proprietary information when importing the WAV files back onto the SSD drive.
That’s the kind of program I’m suggesting that Singular commission. Basically a SONG editor running on a computer that can retain the necessary meta-data while allowing flexible editing of the WAV files and song parameters using the program and a DAW.
It would be a passion project. If I do it, it will just be open source. So no charge.
If it has interest I’ll have a look and see if it passes my laziness threshold.
This feature is already part of our plans and is tied to the backing tracks feature.
Importing and exporting will not need a major portal but we may need to make something for users to interact with on the computer if that is the method they choose to use for the import export process. We plan to also support SD import/export. We also know that there are UI elements and controls a user may need to adequately “bounce” wavs out of the Aeros either in context (considering offsets), clean cut for looping, or raw (extra 360 samples at the end).
We still have some road to travel before this is fully fleshed out but the good news is the backing track feature has recently been pushed a lot further up in our plan.
I do not have dates and cannot give any more info at this time
Thanks for the suggestions!
I’m sorry, but isn’t everything?
Which is exactly and always the problem. What’s worse is I’m willing to help. I’ve written enough of a wave file parser that I am very close to a tool that could to this:
export-wav-to-aeros stereo_input_file.wav CHASP1T1.wav CHASP1T2.wav
And I’m forced to reverse engineer whatever little bit of magic it is the Aeros is looking for.
In this particular case – why not just tell us (me) what it is that makes the Aeros detect a wav file as acceptable to the Aeros? It’s hardly a patentable trade secret, and people would find it incredibly useful. I’m willing to play with this in my own time for my own interest (and to be honest, it’s not even something I need). Why not help me a little? It might be enough of a stop gap to let you lower the demand on your developers. (Even better open source some of your own code, so this work is less tedious).
If you won’t I can still make an attempt. Here we go then.
Here’s the (partial) tree from my Aeros for a 2x2 recording, using a 4/4 time signature, 102 bpm,
quantised, sync start, sync end. I made each part two bars long.
song_2/
├── [ 636164] CHASP1T1.wav
├── [ 636164] CHBSP1T1.wav
├── [ 636164] CHASP1T2.wav
├── [ 636164] CHBSP1T2.wav
├── [ 636164] CHASP2T1.wav
├── [ 636164] CHBSP2T1.wav
├── [ 636029] CHASP2T2.wav
├── [ 636029] CHBSP2T2.wav
└── [ 263] .meta
0 directories, 9 files
Interesting that part2-track2 is a slightly different length. Aeros bug maybe? Might explain some of the desynchronisations we’ve heard reported.
Here’s my tool run in analyze mode on one of these wavs:
[INFO ] --- Analyze song_2/CHBSP2T2.wav
[DEBUG] Reading container, RIFF containing WAVE x 636021 bytes
[DEBUG] - subchunk fmt 16 bytes
[DEBUG] - subchunk data 635985 bytes
[INFO ] Found subchunks ['fmt ', 'data']
[INFO ] fmt: (BitsPerSample * SamplesPerSec * NumChannels = 132300 bytes per second)
[INFO ] Subchunk fmt = {'AudioFormat': <AUDIO_FORMAT.PCM: 1>,
'BitsPerSample': 24,
'BlockAlign': 3,
'BytesPerSec': 132300,
'NumChannels': 1,
'SamplesPerSec': 44100}
[INFO ] Subchunk data = 635985 bytes = 4.807142857142857 seconds
I’m surprised here; I was expecting some additional custom subchunk that had the meta that Aeros looks for. It’s clearly more subtle than that though. I can only guess then that the needed meta information is in the .meta file. That’s gonna be harder to reverse engineer, but nothing is impossible. So let’s hex dump that:
00000000 0a 06 73 6f 6e 67 5f 32 15 00 00 c8 42 1a 04 08 |..song_2....B...|
00000010 04 10 04 58 18 68 01 70 01 80 01 6a 90 01 01 98 |...X.h.p...j....|
00000020 01 02 a2 01 02 00 00 8a 06 14 34 2e 31 34 2e 31 |..........4.14.1|
00000030 30 38 2d 61 65 72 6f 73 2d 34 2e 30 2e 32 90 06 |08-aeros-4.0.2..|
00000040 06 9a 06 60 9a 06 2d 08 71 18 c0 01 52 12 08 c8 |...`..-.q...R...|
00000050 f8 0c 12 0c 43 48 41 53 50 31 54 31 2e 77 61 76 |....CHASP1T1.wav|
00000060 5a 12 08 c8 f8 0c 12 0c 43 48 42 53 50 31 54 31 |Z.......CHBSP1T1|
00000070 2e 77 61 76 9a 06 2d 08 71 18 c0 01 52 12 08 c8 |.wav..-.q...R...|
00000080 f8 0c 12 0c 43 48 41 53 50 31 54 32 2e 77 61 76 |....CHASP1T2.wav|
00000090 5a 12 08 c8 f8 0c 12 0c 43 48 42 53 50 31 54 32 |Z.......CHBSP1T2|
000000a0 2e 77 61 76 9a 06 60 9a 06 2d 08 71 18 c0 01 52 |.wav..`..-.q...R|
000000b0 12 08 c8 f8 0c 12 0c 43 48 41 53 50 32 54 31 2e |.......CHASP2T1.|
000000c0 77 61 76 5a 12 08 c8 f8 0c 12 0c 43 48 42 53 50 |wavZ.......CHBSP|
000000d0 32 54 31 2e 77 61 76 9a 06 2d 08 71 18 c0 01 52 |2T1.wav..-.q...R|
000000e0 12 08 9b f8 0c 12 0c 43 48 41 53 50 32 54 32 2e |.......CHASP2T2.|
000000f0 77 61 76 5a 12 08 9b f8 0c 12 0c 43 48 42 53 50 |wavZ.......CHBSP|
00000100 32 54 32 2e 77 61 76 |2T2.wav|
00000107
The human readable chunks make some of this fairly easy to decode, and that can help us spot patterns. I’ll short cut a lot of the deduction and go for this:
# SONG
.
0a
. s o n g _ 2
06 73 6f 6e 67 5f 32 # Title
. . . . B . . . . . . X . h . p . . . j
15 00 00 c8 42 1a 04 08 04 10 04 58 18 68 01 70 01 80 01 6a
. . .
90 01 01
. . . . . . . . . . . 4 . 1 4 . 1 0 8 - a e r o s - 4 . 0 . 2
98 01 02 a2 01 02 00 00 8a 06 14 34 2e 31 34 2e 31 30 38 2d 61 65 72 6f 73 2d 34 2e 30 2e 32 # Version
. . .
90 06 06
# PART TRACK CHANNEL
. . ` . . - . q . . . R . . . . . . . C H A S P 1 T 1 . w a v
9a 06 60 9a 06 2d 08 71 18 c0 01 52 12 08 c8 f8 0c 12 0c 43 48 41 53 50 31 54 31 2e 77 61 76
Z . . . . . . . C H B S P 1 T 1 . w a v
5a 12 08 c8 f8 0c 12 0c 43 48 42 53 50 31 54 31 2e 77 61 76
. . - . q . . . R . . . . . . . C H A S P 1 T 2 . w a v
9a 06 2d 08 71 18 c0 01 52 12 08 c8 f8 0c 12 0c 43 48 41 53 50 31 54 32 2e 77 61 76
Z . . . . . . . C H B S P 1 T 2 . w a v
5a 12 08 c8 f8 0c 12 0c 43 48 42 53 50 31 54 32 2e 77 61 76
. . ` . . - . q . . . R . . . . . . . C H A S P 2 T 1 . w a v
9a 06 60 9a 06 2d 08 71 18 c0 01 52 12 08 c8 f8 0c 12 0c 43 48 41 53 50 32 54 31 2e 77 61 76
Z . . . . . . . C H B S P 2 T 1 . w a v
5a 12 08 c8 f8 0c 12 0c 43 48 42 53 50 32 54 31 2e 77 61 76
. . - . q . . . R . . . . . . . C H A S P 2 T 2 . w a v
9a 06 2d 08 71 18 c0 01 52 12 08 9b f8 0c 12 0c 43 48 41 53 50 32 54 32 2e 77 61 76
Z . . . . . . . C H B S P 2 T 2 . w a v
5a 12 08 9b f8 0c 12 0c 43 48 42 53 50 32 54 32 2e 77 61 76
# PART TRACK CHANNEL
More to come as I work it out.
Care to help me yet Singular?
Next data dump.
I’ve reverse-engineered the broad format and some detail about the meta file. It’s not complete, but I’m documenting as I progress here in case other people are interested (or I get bored and stop). As a general comment to Singular: this is not an attractive data format, binary is a brittle format and really you only resort to it on embedded projects that are space-constrained, which Aeros isn’t. I also hope you can see by this progress that you don’t really get any secrecy benefit from binary formats. Want to help me yet?
. Conquer the Aeros![MAGIC_NUMBERx1 = 0x0a]
[TITLExN]
[HEADER x20]
= (HEADER[3] = [BPM*2])
= (HEADER[8] = [TIME_SIGNATURE_NUMERATOR])
= (HEADER[10] = [TIME_SIGNATURE_DENOMINATOR])
= (HEADER[19] = [SONG_LIST_INDEX])
[TAG x3] [tag_specific_payload xN]
...
[TAG x3] [tag_specific_payload xN]
...
[TAG x3] [tag_specific_payload xN]
...
[TAG x3] [tag_specific_payload xN]
Some fields are variable length (like [TITLE], they are prefixed with a single byte which represents their length.
There appear to be various [TAG] values, all of the form
9X XX XX
Each tag type has a different payload; and some payloads themselves contain other [TAG]s. Here’s the tag codes I know:
[TAG] Description
---------------- ------------------------------------------------------
90 01 01 section seems to be only present in stereo
98 01 02 section seems to be always present, contains version
90 06 06 parts list container
9a 06 30 stereo _part_ container of 1
9a 06 2f stereo _part_ container of 1, with no measure count byte
9a 06 38 mono _part_ container of 2
9a 06 37 mono _part_ container of 2, with no measure count byte
9a 06 60 stereo _part_ container of 2
9a 06 5f stereo _part_ container of 2, with no measure count byte
9a 06 19 mono _track_ container
9a 06 18 mono _track_ container, no measure count byte
9a 06 2d stereo _track_ container
9a 06 2c stereo _track_ container, no measure count byte
[90 01 01] has no payload, and (so far) appears only in stereo songs. I can find no other bits in [HEADER] that change for a stereo song, so I believe it’s a zero-payload boolean tag.
[98 01 02] has a payload of this form:
[UNKNOWN x7] [FIRMWARE_VERSION xN]
In the Aeros I’m using the version string is 20 bytes, “4.14.108-aeros-4.0.2”. It seems unlikely (and would be dangerous) for an Aeros to rely on any particular string here, because we’d expect a
future version to be able to load past version’s files. But it’s a sensible choice to keep it here because in an emergency future firmwares could work around bugs using this string to tell them it’s needed.
[90 06 06] announces the start of the parts tags. I think it’s best to think of it as a variable length container tag. It’s content will be a variable number of “part” [TAGS]. Given the modes of the Aeros,
there will be 2 or 6.
[PART_TAG0]
...
[PART_TAGn]
[9a 06 30] et al are the [PART_TAG]s. I won’t list them all here, and there are likely additional ones I’ve not found yet (see above table). Their payload is:
[PART_HEADER x4] (not yet deciphered)
[TRACK_TAG0 xN]
[TRACK_TAG1 xN]
For some reason the [OPTIONAL_MEASURE_COUNT] presence (see below) also affects the particular choice of [PART_TAG], with the same one less rule applying here as well. I think it can be safely ignored though, as it’s tracks that have lengths, not parts.
[9a 06 19] et al are the [TRACK_TAG]s. The various values seem to indicate the presence of a measure count field and whether the track is mono or stereo. Their payload is:
[TRACK_HEADER x4]
[OPTIONAL_MEASURE_COUNT] (see below)
[CHANNEL_A_PAYLOAD]
or, for stereo:
[TRACK_HEADER x3] (not yet deciphered, but always `08 71 18`)
[MEASURE_COUNT_PRESENT] (`c0` when measure count present, `60` otherwise)
[OPTIONAL_MEASURE_COUNT] (see below)
[CHANNEL_A_PAYLOAD]
[CHANNEL_B_PAYLOAD]
The [OPTIONAL_MEASURE_COUNT] seems to be added when there is more than one measure; and it’s presence is determined by the particular [TRACK_TAG] used (by observation one less than the numeric value used for the [TRACK_TAG] with the measure count. If it’s not present, then we can assume one measure. When it is presence the [OPTIONAL_MEASURE_COUNT] field seems to store one less than the actual measure count. There’s also some complexity with counting non-4/4
measures. I’ve got a feeling that the definition of a “beat” in beats per minute needs closer scrutiny.
The [CHANNEL_x_PAYLOAD] is
[CHANNEL_INDICATOR] (52 = channel A, 5a = channel B)
[CHANNEL_OTHER x7] (not yet deciphered)
[CHANNEL_WAV_FILENAME xN]It would sure save some time and help avoid the tiny mistake that can screw up any attempt to edit the files if Singular would help you out – make a deal.
Great work!
You’re right that it would help massively if singular would unclench. But I’m not worried so much about wrecking files. Remember the goal here is to take a backing track that already exists and wrap it for use on aeros. That means I don’t plan (at least at first) to edit a song, but to create one. If it doesn’t work, well nobody is worse off than they are now. And I won’t be damaging anybody’s existing loops.
I’ve been programming since 1964 (still do a little) and understand what you’re saying.
What you’re doing is very cool! Thanks.
Can’t wait to give it a try… 
Just add software where we can drag in our out of the the sd. cheers
Hey again,
While we’re planning to work on this as soon as possible and we commend the work you’ve done (quite smart really!), our concern is that the format of the meta information could change resulting in a lack of backwards compatibility with any tool developed at this time.
Additionally, while we’d love to support outside initiatives like this, pulling the development team off of their current tasks to create and share documentation would add a delay to the next planned release. Definitely interesting work you’re doing though!
Thank you for your vested interest, we understand it comes mixed with frustrations, but we are grateful to have your input!
kingofthejaffacakes. Nice try and nice work. I did similar work a few years ago trying to find a more efficient way to get backing tracks on the Jamman Stereo and XT loopers. The programs that could export/import backing tracks to these loopers did not survive the various Mac OS upgrades. So I had to figure out how to do this going straight into the files on the SD cards. I eventually succeeded because on the Jamman series the extra wav data was in separate files so as not to polute the wav files and also the extra date (song title, bpm, repeat or not, etc…) was actually quite simple. And those files could be reused quite easily as long as the folder containing loop data used a strict file naming syntax.
But the Jamman guys had a piece of software that could do all that automatically through software that they never bothered to update for the new MAC OSs.
My suspicion is that the type and purpose of the extra data you refer to in one of your discoveries is simply no longer available to Singular Sound because the original programers have left, and they probably were not good at keeping records of what they were doing. This probably explains also why it takes so long for SS to come up with updates on just about anything. The original programers are gone and the new ones have to do the sort of thing you are doing and it takes ages and potentialy introduces all sorts of bugs elsewhere…
Basically my view is that this is not a good sign for us as users….
In the days of Cobol, a dreadfully boring language, the programs contained more text about what the next syntax line was going to achieve then the actual code! That made it really easy to go back and change things or improve or add features to a program. Its the sort of programming technique that got us to the moon. And yes I started programing on punch cards, using Cobol before moving up to Fortran, Pascal, Basic, C, and eventually even Java…
Now we buy stuff that is programmed by brilliant young programers who just don’t document or stick around long enough for a project such as the Aeros to become what it was announced to be. We all bought a great looking piece of kit for which huge chunks of programing were incomplete.
In the meantime other projects come to market as I mentioned a few weeks ago in another thread and the real Aeros as we know it and use it nears obsolescence already….
Grrrrrr…
Cool - another old timer. I started programming for money in Fortran (before they began putting numbers after it) in the pre-Cobol days. Punched our own cards to be read onto mag tape on a 1401 to be carried to the IBM 709 (tube 7094) for processing - tape to tape - then back to the 1401 to print out - or to draw on the Calcomp plotter.
The (unnecessary) data division used to make me crazy during those times when I wrote Cobol. Writing syntax analysis programs in Cobol was kinda rough too.
My favorite programming was large scale database systems in dBase to dBXl to Clipper to the best of them all Foxpro and Visual Foxpro. I still have a copy of VFP9 on my computer that I used for data analysis and data mining in downloaded mySQL files.
cool…. Will never forget my freshman year, dropping my 200 or so cards on a cold snowy night at two in the morning while crossing the commons on my way to the computer center where I had managed to book a slot to test a program assignment. The old mainframe could not reorder the code and the cards had to be inserted in the right order. The rush to resort the numbered cards by hand in time to not miss the reserved time slot!!! 
…. And them of course you get a syntax error on one of the cards and have to book a slot for the next night… 
. That summer we got a newer mainframe that could sort the cards even if put in the wrong order. A Revolution!!! 
Feeling older but rocking on…
It’s hard not to be frustrated, bordering on angry, with you guys.
Have a read back of the following topic and pay particular attention to the dates on the posts and how soon you said this was coming:
And then compare with what you just replied to me:
I’m sure it could (as I said, binary formats are brittle). However:
You’re kidding? I would hope it’s pretty clear, I don’t need much in the way of documentation. Send me the header file, I trust code more than I trust documentation anyway. Somewhere you’ve got a source file with the information in it: a list of the tag values and their names, the C structures representing them. Send it to me. It should be public anyway. That’s the level of “support” I need.
And on that subject: why are you making undocumented file formats? What spec are your developers working to if the file formats aren’t documented?
As I said: binary formats are not good. Here’s another reason: human readable formats like XML or JSON are self documenting to a degree. So this documentation problem is itself of your own making (and as @chrismcc suspects above, it probably hurts you internally too).
This is really ridiculous. The excuses for not doing something is always “developer time is limited” and now when someone donates some developer time, and asks for nothing more than you would give to the junior developer you outsource next year to do this task, you still say “too much developer time”.
So we can’t have the feature, and we can’t implement the feature ourselves?
Jeez, it’s marvelous supporting smaller companies. Instead of faceless drones ignoring you, you get real people ignoring you.
I agree. But I’m actually of the mind that you hint at in your COBOL observation: the code should be self documenting. I have a colleague that opines that documentation is always out of date, the code is always up to date, so make sure the code is readable and you’re done. I’m not quite that extreme, but I do see documentation as less about covering every possible case and more about being enhanced commentary. Once you understand the “ethos” of a file format or protocol, a quick glance at the code will get you the detail (which is why I’m so frustrated at singular in my comment above – I don’t need help understanding the file format, I’m confident I’ve got it, but there are loads of bytes in headers who’s purpose I don’t yet know, they could save me a lot of time, and won’t).
Quite.
I’m definitely only doing this reverse engineering work for other aeros users. Singular don’t deserve it, IMHO. I appreciate that development is hard, it’s my job so I’m fully aware. But to pretend helping the community help singular would delay a release significantly is one of the more disengenuous excuses I’ve ever heard. It’s what? An hour max to look up a few constants in some source code?
To be honest I would be totally forgiving and understanding of their difficulties if they made it seem like we were a community. That we were closer to some core developer who had been in it from day one and just was implementing a vision. That they participated on the forum too, that they were delighted to share, that it was their small company and loved it. A community liaison who had repository access would be a step forward. But I suspect you are correct, engineering is bought by the yard.
Apologies for being so bleak. Feeling a little disenfranchised.
I understand your frustration and feel the same. Your arguments are good and SS’s refusal to help you develop this little export/import app is dismal and typical. They have our money for their products and will probably ask us for more to get such features or ask us to buy a new unit because the older ones supposedly cannot be upgraded…. We’ve all seen that before. SS are letting their clients down like many other small companies and startups. This is why it is often better to stick with the bigger established companies even if their products have less features. At least they work most of the time and do what they are advertised to do on the box and in the adds. It takes ten years to build a reputation and one second to loose it. SS have spent way too many seconds letting us down and it will take more then 10 years to restore anyone’s faith in them. The Aeros is not their only let down. The progress on BB updates has been just as horrific, and it took months and months for SS to produce apps to program the MM correctly. Think of a midi command module that you buy and you cannot program out of the box and money spent! I own all three because the ideas looked good. I had no idea they were just promises!
Reminds me of Opcode Vision for those of you who may be old enough. Gibson bought the company and let Opcode users down when they stopped supporting the program that used proprietary formats for the audio files. Under massive user protests Gibson eventually released the Opcode Vision code and audi file formats to the user community and open source…
Same with Yamaha and the whole Mlan fiasco! The user community put so much pressure on Yamaha that the company eventualy had to distribute huge discount coupons for other Yamaha gear. I know, I got one q’d bought one of their drumsets at a 60% discount for my son…
In both cases the giants were able to compensate for their failures. I doubt SS will ever do the same as they don’t seem to even have enough money for programers to bring their products up to the specs of their advertising….
Frustrated here also as you can tell….
I’ll stick with Boss next time!
But I am looking forward to your app if you can get there! And will gladly contribute some $ for the app when you know its working.
Best regards