Randomness leading up to
> > There are no useful answers for idiots.
>
> I like that phrase, I'll have to remember that one.
Just for the hell of it, I'll try offering a few
useless answers.
{ it's clear the originator isn't worried about secrecy
or anonymity, given he's using a remote radius server
and asked for help in a public forum. }
{ if he *was* interested in privacy & anonymity, surely he'd
be exploring broadcast or unidirectional protocols such as
digital radio mondiale and not asking us questions. }
1. I'm pretty sure Vincent Cerf didn't intend for any tcp protocols to
survive changing the IP address every minute. Although a lot of his
work seems to have involved machines that were too heavy to carry and
too expensive to re-address every minute, he appears to have
nevertheless been keenly interested in mobile computing & radio use
before either were common. I've no doubt he'd be amused by the
originator's attempt, though I doubt he'd be supportive. The problem
does sound remarkably like a "worst case" roaming scenario with
wireless IP. Maybe something involving a revolving restaurant?
{ Since the originator of this thread appears to have been
relying on what are presumably non-dedicated data circuits &
shared servers, his connections are subject to random delay
depending on competition from other user(s) of those services.
Excessive delay will surely lead to lost data, and snippets
that cannot be pasted together without weirdness.
Presumably those delays will get worse with time... }
2. If you *were* trying to piece together a reliable data feed
out of very short snippets, you'd probably have much better luck
if you managed up to *two* separate overlapping connections --
dropping one once you've sync'd up with the other. Dropping
duplicated data is easier than recreating lost data.
3. If you wanted to use internet protocols to give you a reliable
feed (instead of making one yourself as in 2), you'll want to run
a vpn on top of your physical connection, so that you can then
use tcp to manage packet drops due to the underlying connection
randomly disappearing.
4. "sox" will concatenate mp3 input's together. You'd then need to
re-encode the output stream using some mp3 encoder. sox won't
be capable of recovering data lost due to network drops,
and it's not going to help you with pasting snippets together either.
There is tons of other audio software that can do the same thing,
with variable amounts of fluff and bother.
5. There are a bunch of people who are very keen on matching audio
fragments up. Some phrases they like to use are "audio finger-printing",
or "automatic music identification". Unfortunately these are also the
very same people who tend to be real keen on proprietary data &
software techniques. Fortunately for you, the patent process is
"supposed" to encourage people to provide sufficient information to
make it possible to make experimental use of patented technology.
Unfortunately for you, "supposed to" to a lawyer is rather like what
"possible" means to a mathematician who is asked if the product
of large primes can be factored.
-Marcus Watts
