This sounds a bit like NIH (not invented here) syndrome. I suggest using id3lib to do the actual file manipulation and simply hook Mixxx's front end into that API. This would work for at least ID3v1 and ID3v2 tags.
id3lib http://id3lib.sourceforge.net/ has been around for a while and is used by many tagger / player programs. EasyTAG uses it, and I've used that program without problems for years on tens of thousands of files at a time. This would leave the quality control to a group focused specifically on manipulating audio file tags and metadata. -Scott On Sat, 2012-03-31 at 22:40 +0100, Adam Davison wrote: > Hi, > > I think Albert's general point was more that if you have any memory > corruption anywhere in Mixxx, then the results of our write to the > file are undefined. Even if we fix this specific memory corruption bug > then we have no way to guarantee there aren't more lurking. In fact I > could probably guarantee you that there are memory corruption bugs > lurking in code the size of Mixxx + all the libraries living in our > process space. > > One safe way to do it perhaps would be to have a very small helper > program which handled the writing in a different process. > > Adam > > On 31 March 2012 18:54, Ilkka Tuohela <ilkka.tuoh...@gmail.com> wrote: > > > > Maybe I'm asking the obvious, but why wouldn't following process work just > > fine: > > > > - Store new tags to database fields > > - Make a copy of the file on disk to temporary file, original being still > > mmaped or not doesn't matter > > - Write tag changes to the temporary file > > - If writing temporary file was successful (disk space was enough etc), > > unlink old file and rename new file to original name > > - If writing temporary file was not successful, remove temporary file and > > report error, maybe revert database fields? > > > > At least on unix-like systems, the mmap will hold a reference pointing to > > the original deleted file, and the changes to tags can't affect it, > > preventing corruption. This will use extra bytes from disk for all > > rewritten files (mmaped bytes + new file with new tags) as long as the mmap > > FD is open, but since we don't hold hundreds of files open in player, the > > extra disk space used should not be an issue and is released anyway on fs > > level when the FD is closed by mixxx (song has been played). > > > > Additionally, if we wish to show the updated tags in decks, I think the > > tags should be and are based on database entries not file tags and should > > reflect the current info correctly (as long as there is a slot to update > > the details in player on the fly). > > > > I have no idea if this works similarly on windows filesystems though, but I > > think so. > > > > *hile* > > > > On 31 Mar 2012, at 18:13, Owen Williams wrote: > > > >> I did develop an initial crappy workaround that prevents many of the > >> memory-corruption situations. Basically, if Mixxx can know for sure > >> that the music file is not open, it's safe to update the metadata. The > >> trick is figuring out if in fact that file is open or not. > >> > >> I don't believe there's any risk in corrupting the file on disk. The > >> corruption I experienced was only in terms of playback -- still a big > >> problem because it would cause static during sets. > >> > >> Mixxx is a nice interface for tag editing, though, so it might be worth > >> pushing up the importance of that bug. > >> > >> (one solution might be queuing the metadata update in the file reader > >> object itself, and then writing the data in the destructor. Is it safe > >> to assume only one file object per file, though?) > >> > >> Owen > >> > >> > >> On Sat, 2012-03-31 at 10:38 -0400, Albert Santoni wrote: > >>> Hi Keith, > >>> > >>> I'm sorry you had a crappy experience with this - Our intention was to > >>> reduce the risk of data loss.... which is the opposite of what > >>> happened to you. > >>> > >>> Mixxx did not write write metadata to any music files until 1.9 > >>> because we were concerned that we didn't have the quality control in > >>> place to ensure we would never ship a library-destroying bug. Just > >>> imagine if we had a bug that caused your MP3s to get corrupted... > >>> > >>> And it turns out this fear wasn't totally unfounded. After 1.9 > >>> shipped, Owen tracked down a subtle memory corruption bug related to > >>> Mixxx writing to MP3s, and although there were no reports of corrupt > >>> files, file writing and memory corruption are not a great combination. > >>> (You might be able to make an argument that Mixxx is more susceptible > >>> to heap corruption programming errors which may not affect the actual > >>> file writing itself if it's done on the stack. I'm sure the > >>> TrackInfoObjects are kept on the heap though, so maybe worst case you > >>> could just end up with corrupt metadata. But never say never...) > >>> > >>> As Daniel pointed, it was due to bug #728197 that we disabled metadata > >>> writing for Mixxx 1.10.0 and made a quick 1.9.2 release. > >>> > >>> If you have any suggestions on how we can communicate that metadata > >>> isn't written or want to work on #728197, you know how to get in > >>> touch... :) > >>> > >>> Thanks, > >>> Albert > >>> > >>> > >>> On Sat, Mar 31, 2012 at 4:32 AM, keithsalisb...@gmail.com > >>> <keithsalisb...@gmail.com> wrote: > >>>> Sorry guys, normally I wouldn't say this, but something happened today > >>>> which I really don't understand why this choice has been made, maybe > >>>> someone can explain. > >>>> > >>>> So in the last week or so, I've spent many hours tweaking the metadata > >>>> in my dj library, sorting out track titles, artists, labels, keys, > >>>> bpms all sorts of goodness which makes a record box more than just a > >>>> bunch of files. > >>>> > >>>> It was my assumption all this goodness was being baked into the files. > >>>> > >>>> Yesterday as part of building a new version I moved my .mixxx config, > >>>> and associated database etc out the way to create a new one. > >>>> > >>>> And here it is, to my surprise and quite honestly my shock, my files > >>>> we ALL back to their tatty messed up disorganised state - ALL my time > >>>> and effort had been reverted. > >>>> > >>>> Now you'll notice I was smart enough to backup my data before creating > >>>> a new database, so I've not really lost anything, however I AM upset > >>>> that this happened. I would expect more from Mixxx. I actually trusted > >>>> Mixxx more than Rhythmbox or those other media browsers to do the > >>>> right thing by my files. > >>>> > >>>> So what's the deal here - I can understand a concern allowing users to > >>>> edit their files - sure - but there should be a config/preferences to > >>>> allow me to choose. And more over, I should be made aware that all > >>>> this goodness is not really in my files. Somehow. > >>>> > >>>> My point is, I'm a power user, but I'm sure many users out there have > >>>> edited their files believing they're updating the files, and only when > >>>> they change computers, or rebuild their computer or whatever, that > >>>> they find out all that data is lost. > >>>> > >>>> Thoughts? > >>>> > >>>> Keith > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> This SF email is sponsosred by: > >>>> Try Windows Azure free for 90 days Click Here > >>>> http://p.sf.net/sfu/sfd2d-msazure > >>>> _______________________________________________ > >>>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today > >>>> http://mixxx.org > >>>> > >>>> > >>>> Mixxx-devel mailing list > >>>> Mixxx-devel@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel > >>> > >>> > >>> > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> This SF email is sponsosred by: > >> Try Windows Azure free for 90 days Click Here > >> http://p.sf.net/sfu/sfd2d-msazure > >> _______________________________________________ > >> Get Mixxx, the #1 Free MP3 DJ Mixing software Today > >> http://mixxx.org > >> > >> > >> Mixxx-devel mailing list > >> Mixxx-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > > http://mixxx.org > > > > > > Mixxx-devel mailing list > > Mixxx-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mixxx-devel ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
