search

cyanreg / cyanrip

Bule-ish CD ripper
GNU Lesser General Public License v2.1
232 stars 10 forks source link

README nitpicks #25

Closed q3cpma closed 3 years ago

q3cpma commented 3 years ago

Hello and first of all, thanks for your project replacing the quite bloated whipper for me.

I've had some problems while reading the manual tagging section of the README: 1) The double quotes in the -a or -t examples are actually included in the tag values, which makes the examples pretty misleading, as I'm sure most people don't want that. 2) In the same examples, tag keys don't follow the Xiph Vorbis comments spec (https://xiph.org/vorbis/doc/v-comment.html) where everything in it is all caps. I now wonder if the automatic tagging uses the right keys (only used one CD that wasn't in the database, sadly).

Otherwise, no problem to report.

q3cpma commented 3 years ago

Another problem, how can I embed ':' in my tags? Tried 1 or 2 backslash but it did nothing.

q3cpma commented 3 years ago

Scratch 2), didn't see that the keys were case insensitive.

cyanreg commented 3 years ago

The quotes are definitely not passed on in tags. They don't even make it to cyanrip as the shell simply removes them. Is your terminal doing something weird and outputting non-ASCII quotes which aren't escaped? I know OSX handles quotes in a weird way where they're converted to Unicode quote start/end characters. The quotes are only there to remind users its an easy way to escape spaces, so if your terminal does something weird, you can just use a backslash to escape it, like -a written\ letter. Hopefully, if at least backslashes are ASCII.

The tag keys are automatically translated and converted by FFmpeg to the format's native keys. So for Ogg they're uppercased and renamed, for MP4 some keys are renamed, and so on, and where possible, they're passed on as-is, otherwise they're dropped. FFmpeg's tag key convention thankfully matches what a lot of formats use and follows logic.

-a album_artist="some artist":album="SOME\:ALBUM" -t 1=artist="gibberish":title="other\:name" works for me. There's a bug I found where the lazy way of -a "title":"artist" is problematic when the title contains a : which I don't think I can feasibly fix without scrapping the lazy syntax (which really saves me time). As a workaround, for track or album titles that contain a :, specify some other tag before it, like -t date="2009-09-09":title="A\:SYS". Or just the same tag twice, as the second time the tag is mentioned it'll overwrite the first one's contents. -t 1=title="will not be recorded":title="actual title" or just -t 1="will not be recorded":title="actual title".

q3cpma commented 3 years ago

Yeah, confused the backticks with single quotes while looking at the readme in emacs; which obviously made the double quotes go through. I only tried using the lazy title syntax, good to know the "proper" way works, then.