QAudioRecorder has illogical state / status implementation?
I am using
QAudioRecorderto record .wav files. After the recording finishes, I add an ID3v2 tag to it.
To implement this, I naively relied on the
stateChangedsignal and connected it to my own
onRecorderStateChanged()slot. In there, if the reported state is
QMediaRecorder::StoppedState, I open the recorded file, add the tag to it, and update the "RIFF" chunk's
sizefield by reading its previous size (before adding the tag) and adding the size of the "ID3 " chunk I added.
Or so I thought.
The RIFF size I got for the recorded file was always FF FF FF FF: this is a place holder value that is filled in when the file is finalized, and thus this meant that in the
QMediaRecorder::StoppedStatestate, the file is not complete yet!
statusof the recorder in the
onRecorderStateChanged()slot when the reported
QMediaRecorder::StoppedStateis actually still
statusclearly reflects the actual state of the device, why isn't the
stateproperty consistent with it?
stateis apparently changed before the actual
statuschanges, which seems wrong to me.
I am using Qt 5.9.1 on Windows 7.
Without diving into the bowels of the windows backend, here is an educated guess: the recorder state represent the "mechanical" state of the class, basically, it is "doing something", the status represent what's going under e.g. you push the start button of your car (state), it's not started yet -> there's electrical setup, engine ignition, IVI setup/start (status) and then your car is started (state again). Same when you stop.
QMediaRecorder::FinalizingStatusenum value is likely the most interesting here, especially the last part: Recording is stopped with media being finalized.
The recorder already stopped but there are still steps to be taken in order to have a valid file: closing streams, updating container informations, updating headers etc. depending on the formats/containers used.
Thanks for your input, as always! I will use
statusfrom now on. Cheers.