©2019 Open Acoustic Devices

Jul 26, 2018

Re-writing filenames with date and time

9 comments

Hi all,

 

Not sure if someone has done this here already, but I've created some R code to batch rename a folder of AudioMoth files to apply the date and time they were created. Hope this is of use to others:

 

 

#Convert filenames of AudioMoth to date and time of creation

library(tidyverse)

 

#Set directory to folder containing files

setwd("~/Dropbox (Baker Consultants)/AudioMoth_Rename") #Change this to wherever your files are located

Audiomoth_Dir <- "~/Dropbox/AudioMoth_Rename"

 

#Generate list of files present within the folder

file_list <-list.files(Audiomoth_Dir, pattern = "*.WAV", full.names = FALSE)

 

#Generate vector of creation dates and times

wav_file_info <- file.info(file_list)

new_names <- as.character(wav_file_info$mtime)

 

#Rename files

file.rename(from = file_list, to = str_c(new_names,".wav"))

 

Sep 5, 2018

You can also convert a folder of AudioMoth filenames to date/time format using a hybrid jscript/batch utility called JREN, written by Dave Benham.

 

The latest version of the code is available from GitHub at https://github.com/swingflip/Hakchi-Extra-Tools/blob/master/JREN.bat with Dave's notes from an earlier version at www.dostips.com/forum/viewtopic.php?t=6081

 

Copy the code into a text file and rename it to JREN.BAT then run it from a command window in the folder containing the files you wish to rename using the syntax:

jren "^([0-9A-F]{8})\.wav$" "ts({dt:('0x'+$1)*1000,tz:60,fmt:'{iso-dt}_{hh}-{nn}-{ss}.wav'})" /j /i

 

Note that the option "tz:60" defines timezone +60 minutes to convert UTC/GMT to BST - modify as necessary for your current timezone.

 

Best plan is to call JREN with the appropriate arguments (as above|) from a second batch file (eg jren_am.bat) and save both batch files in a folder somewhere on your Path (I put them in the C:\Windows folder). Then all you need to do is open a cmd window in the folder containing your files and run "jren_am" and all the filenames will be converted.

 

 

Another option is to use the free program Advanced Renamer from www.advancedrenamer.com, which will allow you to rename your files based on the date & time from the "Date Modified" tag (which includes seconds that are suppressed by Windows Explorer). However, whilst the AudioMoth Unix Epoch filename corresponds to the start of the recording, the "Date Modified" time appears to correspond to the time that the file was saved to the SD card at the end of the recording.

 

This is the core part if you like Python:

 

import pathlib

import datetime

import pandas

file_name = '5AAD39B4.WAV'

file_stem = pathlib.Path(file_name).stem

posix_time = int(file_stem, 16)

print('String in ISO format: ',

datetime.datetime.utcfromtimestamp(posix_time).strftime('%Y-%m-%dT%H:%M:%SZ'))

print('String in compact ISO format: ',

datetime.datetime.utcfromtimestamp(posix_time).strftime('%Y%m%dT%H%M%SZ'))

print('String if you are using pandas:',

pandas.to_datetime(posix_time,unit='s'))

 

 

Forgot to copy the result in previous post. Here it is:

String in ISO format:  2018-03-17T15:52:20Z
String in compact ISO format:  20180317T155220Z
String if you are using pandas: 2018-03-17 15:52:20
Sep 12, 2018

Or you can just use Bulk Rename Utility to rename the files incorporating the creation/modified dates and times, plus any additional info.

Sep 12, 2018

Bulk Rename Utility can also correct the UTC timestamps to local time if that is your preference.

 

Sep 12, 2018

You need to be aware that the AudioMoth sets the "Date modified" time to the END of each recording period, whereas the hexadecimal filename (UNIX epoch = seconds since midnight on 1st January 1970) corresponds to the START of the recording. Obviously the difference will be increasingly significant for longer recording times. Additionally the (Windows) "Date created" is set to the time that the file is copied to the PC and not related in any way to the time of recording.

 

The easiest way of converting UNIX filenames that I have found so far (in Windows) is to use a script in "Advanced Renamer": www.advancedrenamer.com

 

To convert UNIX epochs to local dates & times in the format "18-09-09_20-21-40.WAV", select "Script" from the "Add method" menu and paste in the following JavaScript code:

 

dat = new Date(1000 * parseInt(item.newBasename, 16));

return dat.getFullYear().toString().substr(-2)

+ "-" + ("0" + (dat.getMonth() + 1)).slice(-2)

+ "-" + ("0" + dat.getDate()).slice(-2)

+ "_" + ("0" + dat.getHours()).slice(-2)

+ "-" + ("0" + dat.getMinutes()).slice(-2)

+ "-" + ("0" + dat.getSeconds()).slice(-2);

 

If you prefer to keep times in UTC (GMT) then simply replace all the .get... methods with .getUTC... (eg dat.getUTCFullYear() etc). You can save the "Method list" so that the script can be reloaded from the "Presets" dropdown box without having to enter it again.

 

The only issue is that hours are returned in the range 0-23, so that midnight is 00-00-00 rather than 24-00-00 on the previous day.

Sep 13, 2018

Peripherally relevant, but possibly useful too - There is a handy utility from Microsoft which will copy or move files while keeping all the timestamps intact. It also uses multi-threading to copy several files at once speeding things up, and can recover an interrupted copy session.

Sep 14, 2018Edited: Sep 14, 2018

Thanks for that useful information, Justin. I've been using RichCopy for years and never noticed that it copies the Date Created time stamp by default. (The option to turn the feature on/off is buried in the "File attributes / Error Handling" section).

 

It should be blindingly obvious but - for anyone else who is as dim as I was - the "Created" time is when the file was opened on the AudioMoth ie at the start of the recording and the "Modified" time corresponds to when the file was closed at the end.

 

"Ordinary" Windows Copy writes a new Created time stamp but retains the original Modified stamp whereas RichCopy retains or re-writes both timestamps together, depending upon your selected option, and can also re-write them both to a specified date/time of your choosing.

 

One feature to beware of (again it should be obvious) is that if you set RichCopy to copy several files in parallel (increasing the copying speed) the resulting copied files are likely to be highly fragmented, which may or may not be a problem.

New Posts
  • Hi, in all my recordings there's a "clicking" noise (26-28kHz). This is an issue that I had before with some recordings but now the noise is louder and it is present in all recordings. The batteries are Energizer AA (new) and the SD card is the SanDisk Extreme 32GB. Is there Anything I can do to make the "clicking" noise disappear?
  • Amazing work! https://www.openacousticdevices.info/mmoth Clearly it is early days, but obviously so many questions pop into mind ... - Off board Lithium ion battery, with a onboad connecter? (So you can choose any size LiOn? or LiPo? like - https://hobbyking.com/en_us/turnigy-2000mah-1s-1c-lipoly-w-2-pin-jst-ph-connector.html ?) - Any Battery life / runtime estimates vs AM1.1? - Cost? Double side so more expensive? - etc, etc, etc ... Anything else to share with us yet??
  • Hi, I'm attempting to modify the basic firmware, and I'm progressing quite well however there are a couple of sneaky scenarios which require a lower level debugging capability. Can you please advise how you debug the firmware, on the device? I've modified the firmware to call 'AudioMoth_setupSWOForPrint' at the end of AudioMoth_initialise() and added a couple of debug statements such as printf("Debugging enabled"); Throughout the code, being executed. These changes, along with my other alterations were then successfully flashed to the AudioMoth device. I've then connected my J-Link debug probe https://www.segger.com/products/debug-probes/j-link/ , which appears to support the EFM32WG980F256 chip. https://www.segger.com/downloads/supported-devices.php 1. PC -> USB -> AudioMoth USB plug (normal USB connection for an AudioMoth) 2. PC -> USB -> JLink Debug Probe -> SWD via Dupont Connectors -> AudioMoth Debug pads Here's a couple of photos to highlight what I'm doing. Sure, those connections are soldered a little rough but have been verified to be fine. As a simple dump, here's what I'm using. I'm expecting you're doing something similar when modifying the firmware. JLinkExe SEGGER J-Link Commander V6.52c (Compiled Oct 11 2019 15:44:58) DLL version V6.52c, compiled Oct 11 2019 15:44:50 .... Type "connect" to establish a target connection, '?' for help J-Link> connect Please specify device / core. <Default>: EFM32WG980F256 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF> S Specify target interface speed [kHz]. <Default>: 4000 kHz Speed> Device "EFM32WG980F256" selected. Connecting to target via SWD Found SW-DP with ID 0x2BA01477 Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7 ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM ROMTbl[0][4]: E0040000, CID: B105900D, PID: 003BB923 TPIU-Lite ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM Cortex-M4 identified. J-Link> SWORead 0 bytes read (0 bytes in host buffer) J-Link> SWOView Receiving SWO data @ 4000 kHz. Data from stimulus port 0: ----------------------------------------------- Occasionally I'll get SWO output, but its all garbled and meaningless. On other hardware I would think this was a mismatch of the receiving clock (4000 kHz), but maybe I'm attacking this incorrectly. I appreciate this is getting down into the lower levels of core programming on the device but I suspect other users may wish to also understand these debugging aspects when modifying the firmware to suit their needs also. Without a device level debugging capability the only way to check out changes is to flash the device with extra LED flashes to highlight state changes, or log to the microSD via the AudioMoth_appendFile operation. Which SWO debug probe do you use to validate changes to the base firmware? What code changes do you make to enable debugging? Are there Simplicity Studio changes which you utilise to support debugging on the device? Are you debugging the code off the device instead, on a PC using a 32-bit ARM emulator or 32-bit x86 target toolchain? Are you implementing Unit Testing on your version of the firmware?
Before posting, be sure to check the FAQ.