Robin Bowes;179738 Wrote: > > > > > OK, how would you differentiate between a file whose audio has been > > modified (e.g. re-ripped) and one whose tags have changed? > > > > In both cases, the source file timestamp will have changed. > I see your point. For me, it is very rare I that I re-rip a file, but I change tags (mostly genre) reasonably fequently. I guess maybe some people re-rip more frequently than they ammend tags.
Robin Bowes;179738 Wrote: > Here's an idea: Use the MD5CHECKSUM from the flac file to determine > whether or not the audio has changed. > > So, the first time a file is converted, we read the MD5CHECKSUM from > the > flac file and write it as a tag to the mp3 file. > > Next time, we check the mp3 file for a tag containing the MD5CHECKSUM. > > If it's present and matches, we don't transcode the file. > If it's present and doesn't match, we must transcode. > If it's not present then, to be correct, we *should* transcode. > However, > this will cause problems when upgrading from previous versions of > flac2mp3 as no MD5CHECKSUM tag will be present in the mp3 files. I'm > currently thinking how best to deal with this situation. > > R. I wasn't aware of MD5CHECKSUM, but assuming this is a checksum of purely the audio data, that sounds like an excellent (and pretty much bullet-proof) idea. WRT upgrading, how about the user decide not to transcode via a command-line options? Maybe something like *--CopyMd5IfMissing*. This would obviously have to be made clear in the upgrade notes. Thanks very much for the fast response & your ideas. Richard -- SadGamerGeek ------------------------------------------------------------------------ SadGamerGeek's Profile: http://forums.slimdevices.com/member.php?userid=6145 View this thread: http://forums.slimdevices.com/showthread.php?t=32641 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
