Parameters, some questions about time

[nicolemon]

In the spreadsheet, the timecodes given are in the format DDDHHMMSS, ie. 000000000 is January 1, 1969 00:00 GMT.

Parameters

• mission
  • identifies Apollo mission to listen to
  • default is 11, can be omitted for now
  • in the future will be required
• channel
  • required
  • expects a number between 2 and 30 (or whatever the highest channel number is)
  • identifies which channel to include in stream
  • multiple arguments
• format
  • required
  • determines streaming format
  • restrict to M4A/AAC and Ogg Vorbis
• t
  • start time for streaming
  • option: MET
  • default: 0000000 (liftoff)
  • format HHHMMSS
  • will need to support negative number
  • is what we want to display
  • will need to calculate
  • option: timecode
  • default?
  • format DDDHHMMSS
  • easily determine offset for transcript sync times
• len
  • length of time to mix in seconds
  • starts at time t

Example, opt timecode: assuming audio from all ~200 hours of Apollo 11 is available

.../stream?mission=11&channel=14&channel=16&channel=18&format=ogg&t=2012017

starts streaming channels 14, 16, and 18 at time 201:20:17 (July 20, 8:17PM GMT) as ogg. So it will retrieve and mix file 14b (hypothetical name, not suggesting we rename the files)

slice1	slice2: 201:20:07-201:20:27	slice3	slice4	...
14a	14b	14c	14d	...
16a	16b	16c	16d	...
18a	18b	18c	18d	...

edit: added len

Questions, mostly about time

1. Are we going to have the audio server query the database to determine where to find the appropriate wav file?
2. If so, will the database store the MET or the timecode associated with the file?
3. Actually, I propose a static log for the audio server to refer to that contains the following. Thoughts?
   • filename
   • file location
   • MET start time
   • timecode start time
4. We may have to write a function (in the API?) that converts between MET and timecode, so can we establish a way to denote both that's universal across the project modules to minimize re-parsing and conversion?

[austinpray]

Parameters

Looks like you are missing a "length" parameter. For instance if I wanted the first 5 minutes of the mission I would ask for ?t=0000000&len=300 (mission start to mission start + 5 minutes).

edit: confused minutes for seconds, fixed

Answers

Are we going to have the audio server query the database to determine where to find the appropriate wav file?

Yes. The server will query the database, download the appropriate files, and the mix them.

I propose a static log

What does this mean?

We may have to write a function (in the API?) that converts between MET and timecode, so can we establish a way to denote both that's universal across the project modules to minimize re-parsing and conversion?

You are probably right. Everything should definitely be driven by MET however. I think that's simpler. But you are right that we are often going to have to convert MET into datetime especially on the interface.

[nicolemon]

Looks like you are missing a "length" parameter.

Right right, okay, will add.

By static log (poor word choice, probably), I basically just meant a flat text file, comma or tab separated, that can be referred to in order to determine which file(s) contain a requested MET range. Example (with path, MET start, MET end, datetime start, datetime end):

...
/path/to/audiofile1.wav 0000000 0002000 196133200   196135200
/path/to/audiofile2.wav 0002000 0004000 196135200   196141200
/path/to/audiofile3.wav 0004000 0010000 196141200   196143200
...

Irrelevant now, since we've established that we're querying the database.

[austinpray]

By static log (poor word choice, probably), I basically just meant a flat text file, comma or tab separated,

Haha am I the only one that is okay with databases?? Everyone tryna squirm out of dat RDMS

[nicolemon]

Everyone tryna squirm out of dat RDMS

Having the audio server query the DB to get some text felt unnecessarily complicated to me but we're doing the query. You're getting your way, boss.

So is there a DB I can query to write that part or should I set up a dummy DB on my machine? Fer testin'.

[austinpray]

@nicolemon just mock out the calls for now (have a function that returns the correct expected response from the db in the format you want). I will have a real DB up ASAP. The migration for the audio chunk is simple and the db will only have like 16 rows for now.

However, if you do want to create a dummy DB share the SQL you use over at https://github.com/UTD-CRSS/exploreapollo.org-schema so I can make it official.