Re: Best setting for Padding when ripping to FLAC?
The files may be retagged in the future. My question isn't answered, though. We don't understand the purpose of setting the padding to a particular size. What is padding, anyway?
Re: Best setting for Padding when ripping to FLAC?
I thought that may be the reason for the padding, but I wasn't sure. Thanks for confirming that.
If one has, say, a setting of 8kB for the FLAC ID tag Padding, and only a few tags are added, is it safe to assume the overall file size will not change?
Shouldn't the file's Date Modified date and time change when those tags are added at a later point in time?
Re: Best setting for Padding when ripping to FLAC?
In this case, it is mp3tag that we use to update FLAC tags on our server. If there's a setting for that, I'll make sure we use it. Othewise we'll need to alter settings on the application we use (Beyond Compare) to perform binary comparisons betweem folders and their contents, a process that takes longer, when we wish to sync the music library with a backup drive.
Re: Best setting for Padding when ripping to FLAC?
OK! I see that mp3tag has a setting for "Preserve file modification time when saving tags." It is currently checked on this workstation.
By leaving this checked, it allows us to keep track of the entries in our music library by the date when they were originally added.
The downside of this is that our application for syncing libraries for backup will have to be configured to perform binary content comparisons rather than simply rely on file size and date modified to determine if there are changes. Backups will take longer, but just how much longer remains to be determined. We'll need to run some tests to see which configuration profile best meets our needs.
Re: Best setting for Padding when ripping to FLAC?
Originally posted by d2b
OK! I see that mp3tag has a setting for "Preserve file modification time when saving tags." It is currently checked on this workstation.
By leaving this checked, it allows us to keep track of the entries in our music library by the date when they were originally added.
The downside of this is that our application for syncing libraries for backup will have to be configured to perform binary content comparisons rather than simply rely on file size and date modified to determine if there are changes. Backups will take longer, but just how much longer remains to be determined. We'll need to run some tests to see which configuration profile best meets our needs.
Thanks to both of you for your help with this.
I use mp3tag too. Not sure how this will relate to your backup program, but for myself, I ended up "unticking" the preserve file mod date in mp3tag so that my backup program would pick up changes when I edited tags. I found that the binary comparison was taking way, way, way too long. I have about 90,000 tracks in my library. I suspect you have a lot more than that, but maybe your binary compare option is more efficient than what I'm using.
Comment