NCrusher74 / AudiobookTagger

An audio(book)-centric Swift wrapper combining MP4Foundation with ID3TagEditor for tagging .mp3, .m4b, and .m4a files
Apache License 2.0
9 stars 1 forks source link

Putting this here since it isn't related to a current branch #5

Closed NCrusher74 closed 4 years ago

NCrusher74 commented 4 years ago

I need some advice.

Months ago, when I first started looking into ID3 tagging options, I saw OutcastID3 and quickly discarded it as a possibility because:

  1. I didn't have nearly the knowledge I have now and it confused me
  2. I (mistakenly, it turns out) thought it only offered a few tags related to podcasting
  3. I haven't had any luck trying to implement dependencies using CocoaPods

Now, after all this time I've spent actually adding new frames to ID3TagEditor to make it do what I need it to do, it turns out OutcastID3 actually already has all the tags I need, and it offers support for chapter metadata, which is something I'll need down the road (not a lot of players will play MP3 chapters, but some will, and I do intend to create a player that will as part of my audiobook management suite.) And it actually looks like it will be able to unify the writing function with MP42Foundations approach to writing easier than it will for ID3TagEditor.

I guess maybe I'm not looking for advice so much as I am an affirmation that it's okay to change direction mid-stream and scrap all the time I've already invested into making ID3TagEditor work. Though I do need to ask whether or not it's better to stick with ID3TagEditor, which is available using SPM, rather than switching to something that isn't available with SPM.

Should I stick with what I've got an implement my MP3 chapter functionality (as yet undiscovered) another way down the road?

NCrusher74 commented 4 years ago

(the other option is that maybe I can add that functionality to ID3TagEditor by trying to emulate what I see in OutcastID3?)

SDGGiesbrecht commented 4 years ago

If it is useful, go ahead. You don’t have to get rid of the old; you can use both at once and pick whichever is more efficient on a function‐by‐function basis.

Thanks to Git, you also have the ability to easily rewind if it turns out to be a bad idea.

NCrusher74 commented 4 years ago

I'm not entirely which way will be better, but I will definitely need the chapter-handling function down the road, and I didn't want to get too deeply entrenched with one way if I was going to have to rewrite all my code later on.

However, I'm still batting 0 when it comes to successfully using CocoaPods, so I think I'll wait until I'm ready to deal with chapters before trying to add it in.