Open fbnrst opened 8 years ago
Agree that the database duplicates metadata which we could store in the MP4 itself. Consider the current columns:
Getting the recording length requires a little more work to parse out the MP4 field, which @stsydow's patch already does. We might want to store other metadata like tags #16 although the MP4 container accommodates this as well. Given the above, I prefer to remove the database for simplicity and compatibility with other tools.
@dkim0419, do you have an opinion on that? I definitely prefer the file system approach for the reasons given by @andrewgaul.
agreed, using a file system makes a lot more sense. it's a big change though, but eventually it seems ideal to remove the redundant database if we can make use of mp4 metadata. just to be clear, can this work with other file formats too like mp3, wav, etc if we want to support others in the future?
MP3 and WAV both allow metadata via ID3:
https://en.wikipedia.org/wiki/ID3
This appears to be the same mechanism that MP4 uses.
We should embed the metadata in the file so that we preserve it when playing the file off the device. For example, I use the sharing intent to send to Dropbox then listen back to recordings on my laptop. Of course, this does not preclude putting the metadata in a database as well, although storing in two places seems silly.
Currently SoundRecorder uses a SQlite database to track the recordings. If I remove or rename recordings from the SoundRecorder directory manually, e.g. with a file manager, the list of recordings is not updated but the old names are shown. @stsydow appoaches this in https://github.com/stsydow/SoundRecorder/commit/2b4c02e3d21964063df2bbc96a31ebfc971186ac by just using file system and metadata to track the recordings.
Shouldn't that be the preferred approach? What's the benefit of using a database?