Got it, thanks - maybe a link from the discussion of caps in S/L/E to S/T/Eti?
because S/L/E makes it sound like they are all the rules you need to know
regarding caps
For example, that page says "Always capitalize the first and last word of a title. This rule should be followed even if the words would normally be lowercase according to the other rules." Arguably, the whole title is "This is Acid (Jim Hopkins remix)", so "remix" should be caps
ianweller
probably not a bad idea
otoh extra title information is a separate guideline from the english language guideline
it applies to all languages
(last i heard)
brian_b
OK, note/link added to the Style/Language/English wiki page. I presume it gets pushed to the official docs either automagically or based on someone reviewing it?
ianweller
i believe a transclusion editor reviews it
Jormangeud joined the channel
brian_b
can i get some yes votes on https://musicbrainz.org/edit/20218843 ? I'd love to see it committed so I can get a clean rip without having to re-enter a bunch of metadata. The original contributor had a track listing that swapped track artist and track title every other track. Sigh.
the other related open edits on that item would be nice too
hawke_
Voted yes on the tracklist edit.
brian_b
thanks
flamingspinach
brian_b: done
brian_b
Thanks! Does it take more than 3 yes votes to get committed? Or do we wait for a re-index to catch up?
I thought it was 3 yes's and done. <-- n00b
ianweller
brian_b: you have to wait for it to apply
brian_b
ok, and now I see it's done, cool. thanks.
kepstin-work joined the channel
VxJasonxV
I'm very interested in why some files read/write tags ridiculously slow, and others are blindingly fast.
voiceinsideyou joined the channel
some take place at about 1 file per just under a second
other's can do a whole album in less than a second
brian_b
Do tags have to be at the beginning of container files, or might they be appended to the end, or even in the middle somewhere? Could be some of your music has tags at the beginning, others have it at the end, and your app has to scan to the end to find them
hawke_
as far as I know tags are almost always at the beginning of container files…
brian_b
always by common convention, or required to be?
hawke_
Always by most format specifications. :-)
the difference is that some formats allow padding between tags and the music to allow for growing tags in the future
and sometimes you need more space than the padding allows
which means the whole file needs to be rewritten
brian_b
So that would explain why writes can be slow, but not reads
and it wouldn't explain if it was repeatable with the same files
VxJasonxV
brian_b, id3v1 was the only leading tag spec that I was aware of
but it's not solely a format difference. I see some slow m4as vs. fast ones.
I guess it can be a container difference like you said.
brian_b
or where in that container the tag is
if the tool has to scan through the file looking for the tag, that will be slow
VxJasonxV
isn't it always at the end?
brian_b
I don't know
Even if it's only ever at the beginning or at the end, it can be slow to read the end of a file off a disc sometimes
unless you're on some derivative of unix
e.g. linux/macosx/etc
I assume recent Windows releases can quickly seek to the end of a file; I know it couldn't as of a few years ago
VxJasonxV
this doesn't seem like sync times though
it's consistently slow, or consistently fast
also I'm on an SSD
brian_b
that just means your seek time is constant (and fast), compared to a spindle.
hawke_
Usually it’s at the beginning…partly for streaming (I think) and partly since seeking isn’t always fast (or maybe possible).
VxJasonxV
really?
I suppose that is easier for streaming rather than seeking to the end
hawke_
MP3 and Vorbis certainly are at the beginning
VxJasonxV
hmmm
it's strange, it also seems like it matters if the files are being moved across directories or not.
I guess it copies and deletes rather than moving
which does make sense
the tag update I'm doing behaves differently than picard though, for sure
picard exhibits similar fast/slow behavior, but it always moves directoties
Super Jewel Boxes sure are nasty to scan cover art for.
Freso
brian_b: "I'd love to see it committed so I can get a clean rip without having to re-enter a bunch of metadata." - Have you tried using Picard?
brian_b
I've not understood the value of it over Banshee nor what the risks might be with a large collection
what would I get from using it? I can re-tag with Banshee pretty easily
plus I do differ a bit on some metadata, like I prefer "Various" over "Various Artists"
Getting the metadata right before the rip means I don't have to remember to go back and clean up, even if Picard makes cleaning up easier.
But I'm willing to learn more.
nikki
picard lets you change the name used for various artists, at least
brian_b
oh, cool.
nikki
and with the scripting stuff and plugins, it's pretty flexible
brian_b
A big win over Banshee would be if it could pull down cover art and store it as .jpgs locally in each album's directory
nikki
it can
brian_b
w00t
Freso
brian_b: Picard also lets you store the MBIDs in the tags. I don't know if your ripper does that. But that's the one way to make sure you're linking to the exact, proper release/artist/recording, etc.
brian_b
wait, does picard do ripping to?
Freso
(morituri can do that I know, but that's a Linux thing.)
No. :)
brian_b
OK. I do use Morituri for ripping, actually. Except when there's an error on the disc and I need to rip it unsecurely
Any library constraints with Picard? I've got 84K files over 1.4TB
Freso
Don't load it all in at once.
The constraints are more a constraint with your system i/o, memory, and the bandwidth throttling of mb.o. (Unless you're on a slow connection, in which case it would be your own connection. :D)
brian_b
So aside from grabbing MBID's for tracks that don't yet have them, what are the other advantages of using picard over, say, banshee?