Comments (13)
Good catch! e0449bd should address this issue. Let me know.
Off-topic: Why did you submit here and not on Bitbucket?
That was a lucky hunch I guess, as I was planning to move to GitHub :)
from demlo.
It works!
I submitted here because I noticed a while ago that you had put Demlo up here on GitHub, and I figured you were making the transition. On that topic, is go get bitbucket.org/ambrevar/demlo
still the correct way to download the source? If I do go get github.com/ambrevar/demlo
it also works but it downloads the Bitbucket copy as well...
from demlo.
Great!
I'll finish the GitHub transition when I'll release the next version.
Demlo has a few sub-packages that are pointed to by their Bitbucket URI, which is why you get both versions when you try to go get
the GitHub version. I'll change those URI with the GitHub release.
from demlo.
Following up again! This issue also manifests itself for the disc
and track
tags. When editing those tags in-place, they always end up as non-zero-padded int
s, or empty strings, if they cannot be cast to integers. People certainly often want track numbers to be zero-padded, and I see no reason why disc number should be the exception: for all three tags that TagLib wants to be integers (date
, track
, and disc
), Demlo should check to see if the user wants to set it to a string, and bypass TagLib if so.
from demlo.
I'm not sure about this one.
Zero-padding is useful for filenames, but tags need not be zero-padded for filenames to be zero-padded.
Demlo can insert padding in filenames with the path.lua
script.
Same goes for discs.
If your concern is for display in music players, I believe the job of padding zeros belongs to the music player display. To be honest, I do not know why you'd want to pad zeros in a music player display.
Tags should store information, not appearance, i.e. they should store the track actual number, not some formatting of it.
This way, Demlo abides by its own goals: clean up tags and ensure consistency. All tracks will be numbered the same way.
Another use for track numbers / disc numbers is to store the total number, e.g. "1/10" if it's the first track out of ten.
In terms of data structure, this is terrible though: the total number of tracks should be stored in a separate tag.
It would be much more flexible and easy to manipulate. Music players can then easily adapt the display and demlo can easily generate file names without having to parse the track number field.
I do not know if there is a standard field for this though.
from demlo.
Zero-padding is useful for filenames, but tags need not be zero-padded for filenames to be zero-padded. Demlo can insert padding in filenames with the path.lua script. Same goes for discs.
This is true...
If your concern is for display in music players, I believe the job of padding zeros belongs to the music player display. ... Tags should store information, not appearance, i.e. they should store the track actual number, not some formatting of it.
...However, the problem is that not all music players do that. The only way to guarantee that it'll show up consistently is to have the data be stored consistently. In an ideal world you'd be right.
Another use for track numbers / disc numbers is to store the total number, e.g. "1/10" if it's the first track out of ten. In terms of data structure, this is terrible though: the total number of tracks should be stored in a separate tag. It would be much more flexible and easy to manipulate. Music players can then easily adapt the display and demlo can easily generate file names without having to parse the track number field.
I've always gotten rid of tracktotal tags, since I didn't see the point of them—I knew how many tracks there were without being told! But now that I think about it, this would be the best way to do it. In an ideal world, all music files would have a non-zero-padded track
tag and a tracktotal
tag (or some standard name, see below), and similar for disc
and disctotal
, and the music player would insert the appropriate amount of zero-padding. But alas that's not how things work. Many players will show the track as <track>/<tracktotal>
, which I find revolting.
I do not know if there is a standard field for this though.
Yeah that is a problem. I think ID3 has a standard one, but there are probably plenty of Vorbis Comment names in use: tracktotal
, track_total
, totaltracks
, total_tracks
, etc. I consider this the job of a Demlo script to standardize :).
(Continued below)
from demlo.
This way, Demlo abides by its own goals: clean up tags and ensure consistency. All tracks will be numbered the same way.
That is a good argument. Consider this for a counter, however.
The behavior of Demlo in this matter is already inconsistent, simply because of differences between TagLib and FFmpeg. If Demlo uses TagLib to edit tags, then the tracknumber will be a non-padded integer; but if it uses FFmpeg (which is sometimes unavoidable), then the tracknumber will be set to whatever the user asks for, assuming the output format allows it—that is, there is another layer of inconsistency, because the MP4 container does not allow arbitrary tag contents for all tags (probably what motivated TagLib's restriction(?)).
My proposal is to
- Try to do what the user asks as much as possible—by checking
output.tags
to see if ffmpeg is required, and - Be as informative as possible to the user about what is going on—by letting them know (a) when FFmpeg is being used instead of TagLib because of their computed tags (Demlo already does this (per this very issue), though it doesn't mention the reason for its behavior), and (b) when their desired tags cannot be stored verbatim into the output file in the desired format at all, because of restrictions imposed by the format.
I see two variants of the latter situation, for each problematic tag: (i) When the tag can be coerced into the format (by removing leading 0s)—here I think Demlo should proceed; and (ii) when the tag cannot be so coerced, in which case I think Demlo should exit... Or maybe it should set an empty tag in the output (which is what most other software does). Either way it should be verbose (and not require -debug
). Maybe it should be another setting? You probably wouldn't want that... "-forceverbatim
" maybe?
This strikes me as the most consistent route to take that also gives users what they want. Anything would be giving special treatment to track
and disc
over date
.
Oh, and as for why someone might want non-integers in tracknumbers: A1
, A2
, .... Yeah, it's not for me, but I've seen it (and ncmpcpp didn't like it).
from demlo.
Yeah that is a problem. I think ID3 has a standard one, but there are probably plenty of Vorbis Comment names in use: tracktotal, track_total, totaltracks, total_tracks, etc. I consider this the job of a Demlo script to standardize :).
Do you mean Demlo should impose its standard by setting some Vorbis comment such as "tracktotal" when a specific tag is set, for instance o.tracktotal?
Considering how marginal this is at the moment (neither you nor I use this feature), I don't think I'll go that way.
The resulting output of FFmpeg or TagLib should be the same.
The fact that it is not is a bug. I'll fix this.
FFmpeg and TagLib are merely implementation details and the end user need not know about it beyond -debug
.
I think adding some other -verbose
options would add unnecessary complexity.
Regarding the argument of players with bad interfaces: well, it's not Demlo's job to fix them all.
Considering there seems to be no good solution, I do understand the need for more flexible disc/track tags.
I'll turn them to strings then.
Let me know what you think and if you have no further comment, I'll push a fix.
from demlo.
Do you mean Demlo should impose its standard by setting some Vorbis comment such as "tracktotal" when a specific tag is set, for instance o.tracktotal?
Considering how marginal this is at the moment (neither you nor I use this feature), I don't think I'll go that way.
No, I mean it's the job of a Demlo user to customizer their Demlo user scripts to pick one tag and use it. Which is what I currently do.
Considering there seems to be no good solution, I do understand the need for more flexible disc/track tags.
I'll turn them to strings then.
Awesome!
There is one other perhaps-related bug involving those tags that I've been meaning to submit. For some reason, the only way to clear the disc
and track
tags is to set them to 0
—setting them to nil
does not work, and neither does setting them to an empty string. This shows up in the preview output. It's also potentially problematic if the user desires the content of those tags to be '0'. I believe it is a TagLib issue, but the fact that it messes up the preview output is confusing. Basically, FFmpeg should be used whenever the disc
and track
tags cannot be parsed as positive integers. And setting them to nil
(and to ""
) should clear them, just like the other tags.
from demlo.
Sorry for the delay, I'll come back to this as soon as possible.
As a side note, you mentioned the disc
field in this issue, but as far as Demlo is concerned, disc
is not handled by TagLib and thus should not suffer from the integer conversion issue. Am I wrong here?
from demlo.
Hm. You're right. Not sure how I missed that in my testing.
from demlo.
Done, let me know it that works as you expected.
And sorry for the long delay.
from demlo.
It all works great! Thanks!
from demlo.
Related Issues (10)
- Modularize path.lua into basename.lua and directory.lua HOT 3
- Support the full TagLib API HOT 1
- Let -s ignore number prefix of script to include HOT 8
- Emacs mode (GUI) HOT 5
- Overhaul default config HOT 1
- Add completion to `-r` HOT 1
- Self-documenting scripts HOT 37
- Export an 'input()' and 'print()' functions to the Lua scripts HOT 3
- Album-awareness and input ordering HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from demlo.