IPS-LMU / wrassp

wrassp is a wrapper for R around Michel Scheffers's libassp (Advanced Speech Signal Processor). The libassp library aims at providing functionality for handling speech signal files in most common audio formats and for performing analyses common in phonetic science/speech science. This includes the calculation of formants, fundamental frequency, root mean square, auto correlation, a variety of spectral analyses, zero crossing rate, filtering etc. This wrapper provides R with a large subset of libassp's signal processing functions and provides them to the user in a (hopefully) user-friendly manner. The wrassp package is used by the EMU Speech Database Management System (EMU-SDMS) to perform signal processing routines.
http://ips-lmu.github.io/EMU.html
22 stars 7 forks source link

write.AsspDataObj crashes when AsspDataObj contains more than 48 tracks #38

Closed samkirkham closed 3 years ago

samkirkham commented 3 years ago

write.AsspDataObj() causes R to crash when the AsspDataObj contains more than 48 tracks. Objects are binary SSFF format containing EMA sensor data in REAL32 track format. Tested on R 4.0.5; wrassp 1.0.0; Mac OS 11.2.3.

The ‘In Memory Assp Data object’ is returned for the higher track counts (i.e. 112 tracks), so it appears that writing to file is causing the crash. A 48 track object writes, but a 49 track object crashes for the same operation. Different combinations of 48 tracks work fine, so it seems to be the track count rather than anything in the data.

This is not a critical problem as I can write multiple SSFF files instead of one big one, but raising it an issue in case there are known limits on track numbers or header size.

possibly related to issue #32 re: header size?

raphywink commented 3 years ago

ok good to know. Would you have an example file you could send me for me to test? By that I mean somethinkg like an .Rdata file containing the 49+ track AsspDataObj file? That would save me having to create a mock one from scratch...

samkirkham commented 3 years ago

thanks! Sure, see below - the object inside is just called 'ado' (and has 112 tracks). https://www.dropbox.com/s/ui708kf3nel9ai6/assp_example.RData?dl=0

raphywink commented 3 years ago

Perfect! Thanks :-)

raphywink commented 3 years ago

Found the issue: https://github.com/IPS-LMU/wrassp/blob/1411e0d4995d1f14b2c6f991e7b8194d9d8598ee/src/assp/headers.c#L2776 because C doesn't have variable size char arrays it was just assumed (as so often in the history of computing) by the libassp author that headers will never be larger thatn 1kB in size... would be an easy fix for the SSFF file just to say double or x10 that or something (already tried it and if fixes your issue). But that assumption is also used for various other formats throughout the lib and I don't know if it is worth it TBH. Do you think you'd benefit from larger SSFF file header sizes in the future (i.e. more tracks in a single file)?

samkirkham commented 3 years ago

Ok, thanks a lot! If changing this breaks assumptions made elsewhere then I would suggest not bothering with it. I only raised this as my default approach was to write fewer files to disk, thereby having more tracks in each file. However, I've subsequently re-written my function to write a single file per sensor (i.e. only ~20 tracks per file), so it is possible to sidestep this issue via a perfectly reasonable alternative. Happy for you to close if you think appropriate. Thanks again!

raphywink commented 3 years ago

I'll see if I can't at least catch the error somehow... crashing the entire R session isn't great behaviour on our end ;-)

raphywink commented 3 years ago

now catching error in C-lib. Will leave the max size at 1KB as the error says what the limit is.