Roadmap v1.0

I just copied the goals into this issue to keep track of them. We can later just create a checklist out of them.

• Re-factoring:
  • Move away from the readstream approach and use straight file access; a stream is very inefficient in some cases (cannot jump to the end of the file, without reading everything in between) and cumbersome in my opinion. For instance, if a FLAC file prefixed with an id3 header (bad practice, non-standard, but it is done) this code gets completely confused, because it expects mpeg. Moved to issue #7
  • Use Promises.
• Improve tests:
  • Use a test framework like mocha or jest. I used jest for the last project, super easy to work with and supports multi-threaded tests. Moved to issue #8
  • Translate test case code to TypeScript: This brings up more problems than it actually brings benefits.
• Improve documentation:
  • Write detailed documentation on the GitHib Wiki how the tag mapping is done
• New features / functionality:
  • In addition to MusicBrainz tags, support Discogs tags (see #9), maybe iTunes tags
  • Report on errors (see #60)
  • Be able to write tags (see #10)
  • Support audio CRC values

Edit: Concerning the refactoring. It would probably be better to start from scratch and use the current code base as a reference. Changed the title to Roadmap v1.0. Refactoring will probably break the API. Bumping the version up might be a good idea.

[Borewit]

If JavaScript would run concurrent that would be an issue. But is doesn’t. So the whole test block will initialize, including event registration, without any interrupt (ref: Run-to-completion)… So the JavaScript parsing will start after that.

In other words, reading the audio file (by your OS and Node.js) may already happen in the background, but the event handling and parsing it with actual JavaScript will only occur when the previous event handling completed. And everything runs in this event manner, also the initialization of your unit test.

[Borewit]

The test cases would a good starting point.

Regarding the sample files, most of the files I inherited and all files I added, are limited to a very small samples. I guess that is no copyright violation. Would be nice to shrink the larger ones.

The file starts to be parsed immediately. I would expect that the registration of the event handlers are done prior to the first callback. As far as I know JavaScript is single threaded; only asynchronous calls are executed in parallel. Its like a GUI thread.

I suggest to cut down the roadmap into smaller issues.

I will do my best write out some smaller improvements as well.

If you are not familiar with the tool already, please have a look at Picard. A lot of what I added to the original module is based on how this tool works. Try to add some meta-data to some of your music files. Don’t make the mistake to blindly update all your music file, do a single album at a time and review before saving. Select the release manually, Picard will pick one, even if it is unsure what to choose. This is where it all about, if you link with the correct release, it will MusicBrainz augment your music files with the right tags. Based on this identification, If updates are available, you can easily update the music files, or get additional which you cannot even store in meta tags.