Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Easier metadata editing via text file #58

Open
sethkush opened this issue Sep 3, 2023 · 3 comments
Open

[Feature Request] Easier metadata editing via text file #58

sethkush opened this issue Sep 3, 2023 · 3 comments

Comments

@sethkush
Copy link

sethkush commented Sep 3, 2023

It would be nice if it were easier to edit the metadata prior to ripping.

What if there were an option similar to -I that would export the metadata (or a blank template) to some sort of text file (JSON might be good for this)?
Then that file could be opened in $EDITOR, changed as needed, and imported into cyanrip with another command line option.

@cyanreg
Copy link
Owner

cyanreg commented Sep 3, 2023

It's a good idea, but patches welcome - I'm trying to get replaygain to work so I can release 1.0.
Would be nice to reuse that code to support config files too.

@Lebon14
Copy link

Lebon14 commented Sep 12, 2023

(JSON might be good for this)

I'd suggest a simple text file. I'm working on an example right now. I will post the example text files later.
The reason why I think a simple text file is better is because of the familiarity it brings. It's a .txt file, a simple double click and bam, text editor opens and ready to edit. I know that this ripper isn't for the mortals (until there's a GUI). Syntax is not needed, the program just knows how to parse the file and that can be auto-generated with a command.

@Lebon14
Copy link

Lebon14 commented Sep 15, 2023

Sorry for the delay! Two files: the example, followed by the explanations. That made me find some oversight in the features.
cyanrip ripping file example.txt
cyanrip ripping file explained.txt

The oversights:

  • The Drive Speed feature isn't detailed on how it works. Is it a percentage or what?
  • The Paranoia feature setting isn't explained either.
  • In output format, for AAC, there should be an option for the file to be in a m4a file instead of mp4. You might get away by changing the extension but most people are familiar for the audio to use m4a and video to be mp4.
  • As I understand, as of right now, the encoder only support CBR lossy files. VBR and ABR should be added. Since MP3 uses a different encoding setting for VBR, a new line was added to set a value between V0 and V9. The lossy mode should get its own command flag as well as MP3 VBR (if needed).
  • As of right now, filename sanitation is awkwardly worded. It defines two values but otherwise isn't really documented. I added the values "Windows", "Mac" and "Linux" to make it clear that the sanitation will take into consideration the OS entered. That said, "OS_UNICODE" should be removed; only simple remains as this will just remove any characters that can cause issues.
  • Art embedding: There could be four different options here. User provided file (EMBED_FILE), user provided url (EMBED_URL), automatic lookup (EMBED_QUERY) or no embed (boolean EMBED_ART).
  • The album metadata should be working roughly like described in the original documentation? Anyway, nothing goes into quotes because the user could use quotes as part of the album name. The "=" should be the start of the metadata and ":" on the next line the end (the first pace after the = should be ignored). Number of disc and tracks values are between quotes that means that they will take their value automatically from either the "MULTI_DISC" command or the number of tracks polled from the disc. You can delete them, it'll just override these automatic values.
  • Now, there could be more tags for tracks such as Composer or Performer but I went for the minimum. It works like the album meta. The "ALBUM" value between quotes will get the value from the "Album Artist" tag from the disc info. Overriding it is expected as it'll be used for compilations.

If any questions, just let me know here. I'll check here later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants