Hm, this should be supported in vgmstream but apparently it doesn't work (at least in the old r1040 build with the reference decoder .dll, kode54's foobar2000 component uses a different decoder and might work differently). Maybe there is some more structure to the file than the raw stream? Maybe the frame size is different (s14_sss.c assumes 0x3c, and these files aren't multiplies of that size).
edited 9:10 PM EST February 20, 2016
[edit]
Yep, frame size is 80 (0x50), which I think means 32kbit instead of the 24 kbit assumed previously. Here's a hacked version of test.exe r1040 which will work: test_hack2. (you will also need the external DLLs)
Each file is only one channel so you'll have to combine them separately, vgmstream's dual file stereo support doesn't activate with this format (no reason why it can't, though).
edited 10:57 PM EST February 20, 2016
Ah, yes there is (a reason why DFS can't work), the ugly hack of my decoder shim doesn't work in two channels.
---
Yikes, S037CLEAR_0ch.s14 needs a frame size of 120 (0x78, 48kbit).
Also, I remembered where else I saw Siren14 files. It wasn't another DSiWare like I thought, it was a DS game called "Hottarake no Shima - Kanata to Nijiiro no Kagami". Your modified test.exe handles the files from that game. Here's the "Siren14" folder from that game in case you want to look at them: http://www.filedropper.com/hottarakenoshima-kanatatonijiironokagamij
Here's another hack for 48kbit like S037*: test_hack3
I'm realizing that I should be probably decoding an additional 40ms due to the latency, this is particularly noticeable with S037* as it cuts off a little early.
Probably not going to get around to fix it, though. Did all this hacking with i586-mingw32msvc-objdump and hexedit. Sick of it.
Don't know if 32678 Hz is really appropriate either, 32000 Hz even might be correct. Not sure why I did the other thing.
The issue is that it isn't easy to tell from the file what the frame size is. There would have to be something like GENH or a decoder that tries to figure out what looks like a valid stream (try decoding at 0x3c, 0x50, and 0x78 to see if the second frame picks up there). The reference decoder doesn't report any errors (that I noticed), just decodes to silence, so that would have to be modified. Maybe your decoder can get the job done better?