View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002738 | MMW v4 | Properties/Auto-Tools | public | 2006-12-22 10:55 | 2007-02-06 05:48 |
| Reporter | jiri | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.5.4 | ||||
| Summary | 0002738: Some tracks remain in Unsynchornized Tags node even after Tag Synchronization | ||||
| Description | As reported by several users, some tracks remain in Unsynchornized Tags node even after Tag Synchronization. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Fixed in build 1012. - It was caused by the fact that tracks tagged by our format plug-ins (FLAC, OGG, ...) couldn't clear fields, i.e. there always remained some text. In the example tracks send in by a user, it was: Comment field in DB was: '' Comment field in FLAC filed was: 'some text here...' Even after tag write operation, the comment in FLAC file wasn't empty. |
|
|
Tested in 2.5.5.988 and this seems to work except for a WAV track that I can't seem to sync. The specific track 'Son of a preacher' is posted to the ftp server. Note: I've left this at 'immediate' however, in truth I think that given the fact that wav isn't used quite as often, and given that this doesn't usually occur, it might be ok to push. |
|
|
It is caused by a corrupted WAV file. We could possibly try to fix such a corrupted file, but I wouldn't consider it as too important, definitely not for MM 2.5.5. Assigning to Peke to review, whether we could easily fix the file so that tagging works. |
|
|
I do not know what to do about other formats but in case of Wave and by its Specs. Wave file Metadata can contain multiple JUNK Fields and in case of such corrupted files, Jiri corrected bug 2735 and that is the main reason why I made those slowdowns when reading corrupted files (in that particular case each CHAR read should be counted and On Write Tag should be replaced with JUNK field. On next MM read of that file File will not be corrupted). My every Plugin has unfinished Function that will internaly handle Clear/Delete any metadata left for use in the future. |
|
|
Peke, I don't understand what are you trying to say. I particularly don't see any relation to 0002735 where I didn't make any functionality changes, but rather only made code much safer and faster. Is it possible to improve the code somehow to properly update the mentioned file? Or will it be if we implement Tag deletion from files as we currently do only for mp3s? |
|
|
For Wave File I can try to improve code to make needed fixes to file, and also if we make clear tags available in other formats it can solve future formats. |
|
|
Assigning to Peke to try to implement the fix. |
|
|
I'm not sure I understand why we'd want to WRITE to the tag during a read operation (which is my understanding of what Peke's proposed solution is). Can you clarify. |
|
|
If I got Jiri right, no writing will be done on Reading, but MM will write correct (Will correct) Metadata info and fix corrupted file chunks by marking them as JUNK. |
|
|
Yes, there won't be any tag modification while reading tags. Only when user writes tags to tracks, WAV plug-in can try to fix the issues found. However, as I wrote, I don't see it as critical, I'd do it only if there isn't any risk involved. |
|
|
Regarding solving 0002780 , 0002778 , and several performance issues in scanning thrum corrupted file. No changes are made during reading of file. On Write Tag MM will scan thrum file for detected corruption frames and artifacts and mark them as JUNK. Which results In Faster scanning trhum file. |
|
|
SVN Updated Fixed, I have tested on 0000423:0001500 Files including all the bugs we had with F_WAVE. |
