Renaming workflow : WAV/BWF BAE Support or MP3 id3v2 calculation

Support
1

Hi, I'm not so newbie MP3Tag but a bit newer at recording audio.
I'm doing like "forensics" audio recording, depending on what result expected I use MP3 or WAV (BWF). Those come from "Zoom H4n pro" recorder.

Whil recording in WAV format, the BAE "time recorded" or "start recording time" is in the WAV file (seen with several utilities)

While recording in MP3 format, there is no indication, just I can find "file_mod_datetime" thru Mp3tag, in fact this is the time of "stop recording".

In order to have an improved and efficient workflow, I need to rename files this way :
YYMMDD_HHMMSS_ kHz_Bit_[Original file name]

Where YYMMDD is trivial recording date
HHMMSS is start recording time : either the BWF start timecode or MP3 file_mode_datetime minus duration
kH is sample rate
Bit is depth of file encoding. (or Bitrate for MP3)
[Original file name] is trivially what is it.

I wish I can Batch these renaming process (it permit other plug-ins to time stamp datas in audactiy) wit MP3tag.

So I just need support to know if BWF chunk will be supported in near future ?
(in order to directly read timestamp the transform it to HHMMSS)

For MP3 I've Tried to add a clolumn with : $sub(%_file_mod_datetime%,%length%) value, having bad results. I should need some help right here. Any support ?

Thanks for your concern.

2

I think you have to calculate with the "raw" values and not the formatted ones.
See the help on some of these time properties:

3 
$sub(%_file_mod_datetime_raw%,%_length_seconds%)

Yep, I do have tried and it works just fine, I just can't figure out how to display this unix format in human readable date. Then export it as I want to.

Now I just succeed in adding a calculated column.

I'm in deep RTFM2.0 Help reading, but may be not have take this thing by the correct way. I will inquire the community about "workflow".

Thanks for your support.

4

Perhaps this remote page helps:

5

Actually, there are also

%_file_create_date% Short creation date
%_file_create_datetime% Long creation date
%_file_create_datetime_raw% Long creation date (unix timestamp)
So, ideally these dates match the start time of recording.
6

In an ideal world yess I was thinking so.
In "Zoom" world, seem that's not so obvious
the H4n Prom firmware is a big mess in file processing, stocked info aren't the same between MP3 and WAV format ! the real timestamp exist only in WAV/BWF !

If the recorded file is bigger than 2Gb then it is splitted and in MP3 the recorded time is the end time of whole record session. Only WAV do remember the recording starting time of each file.
it's a mess.

In fact '%_file_create_date%'* are the system time the file is created on the backup system (while copying from SD to HD). in MP3 the closest real time is the %_file_mod_datetime_raw% only true while file is not modified (i.e. not Tag by mp3tag for example)

Still searching. (this site is so huge !)