This is mostly an SDIF question, but as it is in the context of trying
to get "sdif2mp4" working, and understanding how the SAOL fft opcodes
work, I have cross-posted.
Firstly, and most quickly, I can convert a 1TRC SDIF file into mp4, and
render it correctly using SAOLC, but sfront v61 (still) finds errors in
the mp4 file.
I have seen that the 1STF spec has recently been updated, with changed
information in the info matrix, which is fine - I will adapt my programs
to that. It does mean that the SMS programs are also out of date now.
"SDIFDisplay" (which I have built for Windows as "SDIFVIEW") ignores the
info matrix, so should be unaffected.
My main problem:
Despit all my hacking so far, I can't get a proper resynthesis of my
test input.
What actually is the structure of the analysis data in a 1STF frame? The
spec just refers to "real Part" and "imaginary Part" "as it comes out
from the STFT", and adds that "You can convert these numbers into polar
form to get magnitude and phase".
I understand from this, as well as from the formula posted on the
relevant CNMAT page, that the rows run from DC up to Nyquist, as re:im
pairs.
Sdif.saol reads these frames without modification, and passes them
directly to the ifft opcode.
The problem here is that according to all the SAOL documentation, the
ifft expects a full mirror-image complex spectrum, with Nyquist at
size/2 for each array. This would therefore appear to be a different
format from that defined by SDIF, but sdif2mp4 does not adjust the array
data. The amplitude level expected in an 1STF analysis frame is also not
defined. The inverse window code in sdif2mp4 seems completely wrong; I
get better results just using a neat Hamming window without scaling.
[ I can't avoid feeling that of all the formats that SAOL could have
selected, the mirror-image format is the least convenient, for
modification purposes, as two array elements have to be modified for
each change to a frequency bin. A straight re:im ordering up to Nyquist
would be far more conventient, and is the form supported by the majority
of current analysis programs.]
So on the face of it, sdif2mp4 is incorrect as published because the
analysis frame formats are not directly compatible.
There is also a question over the name of the info matrtix for an 1STF
frame. Some documents have it as "ISTF", but others have it as "1STI",
which I thought was reserved for the general information frame in an
SDIF file. The SMS software uses "ISTF". Conversly, the sdif2mp4 code
only has "1STI", and that is also referred to in the AES99 paper "Audio
Applications..."
I do think that a canonical rewrite of sdif2mp4 is timely. I am trying
to run my SDIF files through sdif2mp4 etc to test them, but it is really
perilous because:
1: even though the frame sturcture of my SDIF file is correct, the
structure of the analysis data (for which I am using CARL pvoc), may not
be.
2: I am dependent on the file sdif.saol, which I also suspect is not
correct.
3: I am also dependent on SAOLC, which (I think) works, but may or may
not be passing mp4 files that have problems.
3: I ~would~ like to be able to test with SFRONT, but that always finds
one problem or another with the mp4 file!
It would be really snappy to manifest a final working convergence
between SDIF and SAOLC/SFRONT in time for ICMC.
Richard Dobson
-- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 17th September 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:57 EST