Hello Commanders,
I did some recording and (basic) analysis of the obelisk audio and thought I'd share what I've found so far.
Hypothesis:
For the purposes of this experiment, I am hypothesizing that the obelisk audio contains data (of some type) which is visually detectable in the audio's spectrogram. Furthermore, I propose that the data is being streamed "server-side" (as it were) and does not start at a given packet, record, offset, etc. upon activation of the obelisk.
Clarifications on methodology:
* Please note that all recordings were done in solo mode.
* Prior to recording audio, I parked far enough back from the obelisk to ensure that it was deactivated and then exited to the main menu.
* Initial recordings were in 32-bit stereo at 48000Hz. The long recording (discussed below) was in 32-bit mono at 48000Hz. As both channels were identical, I only went with mono to make comparison of tracks easier.
Recording Session #1:
- Start game in solo.
- Turn off wave scanner.
- Begin audio recording.
- Pull forward close enough to obelisk to activate it.
- Monitor spectral view in Audacity until two "data packets" have been observed and recorded.
- Stop audio recording.
- Target and scan obelisk and note which type of data it says it has.
- Log out.
- Repeat from step 1.
Results:
After 10 iterations of the above, I found that no two recordings looked alike--even those that showed as the same data type when scanned. Also, the audio appeared to be in the same format when scans returned one or two data types (sometimes scans will return multiple data types, even two of the same kind).
Recording Session #2
For this process, I recorded in 32-bit mono at 48000Hz following steps 1-4 from session #1 above. The deviations here were that I recorded for four hours straight and that I didn't scan the obelisk after the recording. The recordings in session #1 didn't seem to show any change in the observed spectrogram data between scanned data types, so I decided to leave that step out.
Please note that there are several spots in the long recording where I had to re-fuel my SRV. I made sure that I did that between data packets, so it didn't interfere with the spectrogram data.
Results:
In the entire four hours of recording, I did not see any repeated data packets. In that four hours, however, there were only a total of 113 data packets recorded.
The number of data packet recorded for each hour were as follows:
* Hour 1: 27 packets
* Hour 2: 29 packets
* Hour 3: 29 packets
* Hour 4: 28 packets
Analysis of the Long Recording
Using Audacity, I copied each data packet into its own trimmed track in a new window. With the tracks stacked this way, it's easy to see that there is a space before the large block at the "end" of the packet that is common among all tracks. Even so, with all of the tracks left-aligned it was difficult to spot any significant patterns.
The "left-alignment" got me thinking, though. What if we're seeing this data in memory address order? By that, I mean that maybe the data is being streamed byte-by-byte as it's written in "memory." If that's the case, and the data is stored with the least-significant bit/byte first (Little Endian), then the data packet should be viewed the other way 'round. If you're not familiar with Little Endian, a quick Google for "byte order endian" will get you more than enough information on the subject.
Going with that idea, I reversed and left-aligned the tracks again. A screen cap can be seen here.
To me, it's much easier to spot that there are patterns in the "data." Here is another screen capture hi-lighting some of them. I'm not 100% sure whether or not the spacing being off a bit matters, so the one's I'm not sure about have a "?" on them.
I haven't gotten much further than that, but I wanted to put this up here for others to ponder while I continue to stare at it all.
Here is a link to a shared Google drive folder where you can find the original 4 hour recording as well as all of the Audacity projects that I put together. I zipped everything with 7-zip, but can convert to standard .zip if anyone needs it (just let me know).
o7 CMDR Stick152
Yours is an AMAZING piece of science CMDR!
I'm still pondering about it....
tons of REP!
- - - Updated - - -
what programs are you guys using to record the ingame sound with and do the spectrographs?
For the spectros use Sonic Visualizer: it is super easy!