Hello again!,
First of all, thanks so much for the quick replies!.
@kozikowsky and Gale: Thanks so much for your suggestions, there are great and most useful!.
@Edgar: basically, what we have is an automated process that will allow end users to edit sound files for them to remove specific portions of it. Once they finish editing the file, we compair sizes between the original and the edited copy to check for changes, as we don’t want users creating duplicates of the original files; if the edited copy is smaller than the original one, then we process it, if it isn’t, then we don’t. For this, we have a script in place that checks both sizes and file formats.
So, if users select a different file format for exporting their edited data, we would still be on a good spot because that file will not get processed… however, end users are often not the brightest kids out there and if they indeed save the file in, let’s say mp3, we will secure our information, but the process will fail and they will start complaining about it, regardless of who’s fault is it.
Because of the above, we were thinking of restricting Audacity to just save files as the only format we would accept for processing, thus eliminating any creative moments end user might have.
We do have development teams but they are not involved in this effort, as we deal in engineering. Users would just cut out chunks of audio, so no advanced functionality is needed: just for them to open the file, delete whatever needs to go and save it.
I’m a PHP/Actionscript coder, so, that wouldn’t help either =P
We can actually make this happen with Audacity’s default functionality with no problems, but the idea behind my enquiry was to see if there were ways to tweak-up the app in a restrictive way to eliminate any room for human error.
Again, thanks so much for the help and, if further details are needed, please let me know.
I can’t thank enough! =)
Sebas