QAudioRecorder has illogical state / status implementation?
-
Hi,
I am usingQAudioRecorder
to record .wav files. After the recording finishes, I add an ID3v2 tag to it.To implement this, I naively relied on the
stateChanged
signal and connected it to my ownonRecorderStateChanged()
slot. In there, if the reported state isQMediaRecorder::StoppedState
, I open the recorded file, add the tag to it, and update the "RIFF" chunk'ssize
field 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::StoppedState
state, the file is not complete yet!The
status
of the recorder in theonRecorderStateChanged()
slot when the reportedstate
isQMediaRecorder::StoppedState
is actually stillQMediaRecorder::RecordingStatus
....Since
status
clearly reflects the actual state of the device, why isn't thestate
property consistent with it?state
is apparently changed before the actualstatus
changes, which seems wrong to me.I am using Qt 5.9.1 on Windows 7.
-
Hi,
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.
The
QMediaRecorder::FinalizingStatus
enum 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.