Album-awareness and input ordering

[Ambrevar]

In #4 we mentioned the issue of auto-numbering tracks according to their position in the queue.

There are several ways to proceed. Some do not cope well with parallelization.

Using the queue order in the script is not very flexible though: what if the sorting (which depends on the locale) does not suit the user?

Probably better: add a directory listing function. That should not harm the sandboxed nature of Demlo. By matching the track path with the directory listing, we could auto-number the tracks.

[Ambrevar]

Other things to consider: online tagging needs some sort of album awareness to identify albums, to instance the total track count.

For maximum flexibility, we could simply dispatch the online tagging function (and covers) to a script. This way it would be possible from the Lua side to first gather the list of files in the current directory to infer the total track count, then tag online.

What about reading external file tags from the Lua side? This would probably require some sort of caching too avoid excessive I/O. Export a metadata function then?

[fictionic]

For maximum flexibility, we could simply dispatch the online tagging function (and covers) to a script. This way it would be possible from the Lua side to first gather the list of files in the current directory to infer the total track count, then tag online.

This seems like a good idea, yes. Though "the currently directory" is not general enough, since the user can pass in any list of files they want.

What about reading external file tags from the Lua side? This would probably require some sort of caching too avoid excessive I/O. Export a metadata function then?

I don't understand what you mean by this. They're read on the Go side and accesible via input.tags on the Lua side—why should this change?

[Ambrevar]

Current directory: Indeed, any directory is even better and it comes at no cost.

External metadata: because the input and output structures accessible on the Lua side only refer to the current track. What if you want to count all the tracks that have the same album? You need to inspect their metadata and right now there is no way to do that from a Lua script.

I suggest two functions:

• list_directory(path string) []string
• metadata(path string) input{}

[fictionic]

Oh, I see. Yes I've had a thought about this. I think that could indeed work if caching is done. Here's another option: Have a table inputs that's just a list of input tables indexed by a canonical ordering of files/directories. Then add a field index to each input table, specifying where in the inputs array it is.

Wait, why do you want the metadata() function to take a path as input? Can you give a use case for that?

[Ambrevar]

I think inputs would be unnecessarily complex while caching does the same job transparently for the user.

metadata: Well, it takes the path of the file from which to get the metadata. Did you expect something else?

[fictionic]

Did you expect something else?

Well I'm just imagining that it would be hard to use. How would you know the path when writing the script? With my input method, you could have a script do preprocessing by iterating through each input to get a list of unique album names, number of tracks for each album, etc. How would you accomplish this with metadata()?

[Ambrevar]

The problem with the inputs table is that it must be built beforehand, which severely impedes the parallel processing.

Besides, iterating over the full table for every track does not scale well to big folder hierarchies.

Concrete example with what I suggest:

tracktotal=0
for _, j in pairs(list_directory(dirname(input.path))) do
  local in = metadata(j)
  if in then
    stringrel(in.tags.album, i.album) > 0.7
    tracktotal = tracktotal + 1
  end
end

[fictionic]

The problem with the inputs table is that it must be built beforehand, which severely impedes the parallel processing.

This is true. But how is caching all the metadata beforehand any faster? Isn't it the exact same thing?

Besides, iterating over the full table for every track does not scale well to big folder hierarchies.

That's certainly true as well. Let me think about that.

[Ambrevar]

Caching is faster because it's done on demand (i.e. laziless in technical terms) and not beforehand.

[fictionic]

Ok I see what you mean. It's the same speed if you do end up looping through every input file, it just wouldn't do that every time unless you tell it to.

[Ambrevar]

Exactly.