proposal: event for identification of the type of stream

[leetreveil]

proposal: event for identification of the type of stream

[leetreveil]

This is probably pushing the boundaries of the potential use cases for this library slightly. Let's leave it out for now, good idea though 👍

[andrewrk]

okay. To be clear, this isn't just a random API idea that I had. This must be done somewhere for my music player app to recognize which files to put in the library. So I'll either have to maintain a fork or have a library that sits in front of musicmetadata.

[andrewrk]

Really what I need is the ability to distinguish between audio files that have no metadata tags, and non-audio-files.

[leetreveil]

Could you not use this?: https://github.com/broofa/node-mime

[andrewrk]

file extension based? I don't see why I'd even bother to translate the extension into a mime type then. I could just have a set of acceptable file extensions.

But guessing based on extension is not quite as robust as actually checking the metadata header.

musicmetadata contains useful logic for determining the content type of a stream - why not expose it?

[leetreveil]

Lets say you have 100,000 files on your computer.

Having to read some data from every single one of those files just to find out its mime type would take forever.

[andrewrk]

If I have 100,000 files on my computer, all the more reason I need to build an index of artist/album/title etc for the music library. To build an index I need to read some data from each file, including the metadata. To even read the metadata, I have to learn the file type. The work will be done regardless.

[leetreveil]

Lets say only 1000 of those files are audio files, all mp3s.

You could do two things:

Read the first n bytes of every file to detect the mime type. This involves opening a file descriptor, numerous sys calls, never mind actually having to read bits from the disk.

Or you could just filter on the file extension.

[andrewrk]

okay I see why we have different mindsets: Your use case is scanning your entire hard drive; my use case is scanning, for example, /home/andy/music

I still think this principle holds true: if a module/library calculates or learns something nontrivially useful in the course of doing its main task, that information should be exposed. Otherwise API consumers will try to duplicate (poorly) the functionality, yet depending on the 2 different codebases to do the same thing.

Are you mandating that this module keep secret which decoder it ended up using on the stream?

[leetreveil]

I just don't see the value proposition for this feature, sorry.

Either the library will emit a metadata event or it wont.

[andrewrk]

For reference, here's what this looks like: https://github.com/superjoe30/node-musicmetadata/commit/7f922555d386d5f39c741640694a639e6f45cf63