View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001628 | MMW v4 | DB/FileMonitor | public | 2004-11-22 04:52 | 2004-12-16 15:30 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 2.3 | ||||
| Summary | 0001628: Scanning hangs on some files when scanning is enabled for .wav files | ||||
| Description | When I run the startup scan using the default settings + MPC + APE, everything works correctly. When I scan with .WAV enabled, MM locks up during the scanning process, and CPU utilization stays stuck at 100%. The only way out is to shut MM via the task manager. I'll post a log to the ftp server. | ||||
| Additional Information | Note: the ftp server contains a zip file containing: 1) the log 2) the directory that appeared at in the status bar of MM when it froze (2202_05) 3) the first 4 files in the directory that appeared in the log when it froze (2002_09) | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 819 | ||||
|
|
I tested this and assigned to Peke because the bug seems to be in f_wave.dll. Specifically whenever FORMAT_OpenFile of f_wave.dll is called for RIM00042.WAV (as uploaded on the FTP) it takes very long time and doesn't return back to MM. Maybe it's even random because once I tried this the track appeared to be scanned. |
|
|
Reminder sent to: peke |
|
|
Found some typing problem will be resolved ASAP. |
|
|
I have reviewed bug more thoughly, and it looks much worse than it looked on first site. It can be solved but unfortunatly, Search part and detection of correct INFO Chunk (Metadata) must be rewritten, as in case of Rustys RICOH DC-4 Wave file has its own INFO Chunk named 'exif' where all metadata is written, including name of jpg supplied with Wave (RIM00042.jpg) a snapshot??? Note: By Riff Spec. INFO Chunk is at the end of RIFF. As specs are not strict like MP3 and Windows itself skips metadata it will be playable what ever junk is written in file. I need suggestions what to do ASAP as This can couse big problems and data loss as more and more devices/softwares uses these holes in Spec. Futher more: It is not difficult to make fix but what to do? Ingnore them or delete and make new one according to spec, preserve own format and read only available? example: - RICOH DC-4 Riff format - 1. Riff Header (By the spec) 2. INFO Chunk/Metadata: INAM, IGNR, ICMT and IART all filled by Blank spaces; also it writes correctly ICRD(Creation date) and ICOP(Copyright) '(C) by DC-4 User ' 3. new metadata info chunk (its own info chunk named 'exif')with metadata fields 'ever'->Version '0200', 'erel'->Related to 'RIM00042.JPG', 'etim'->Time 12:33:00, 'ecor'->Hardware 'RICOH ', 'emdl->Model 'DC-4 ', 'emnt'-> Hardware revision/serial?? 'Rv0157;Aj0000;Bn0000000;Md4900:', 'eucm'-> ???? 4. Audio Stream --- File end ---- - Riff Format spec example (Windows sound event used in themes, Sound forge, AudioTron, Sound recorder, ...)- 1. Riff Header (By the spec) 2. Audio Stream 3. INFO Chunk/Metadata: INAM, IGNR, ICMT and IART all filled by Blank spaces; 4. ICON metadata (Can be used in Album Art can be foun only in some files) - end file - Personal observation note: That RICOH metadata contains privacy information which can be misused even to track you if 'emnt' is serial. |
|
|
Reminder sent to: jiri, rusty |
|
|
I would suggest that if this is in fact 'non standard' then, at least in the short term, it would be sufficient to simply scan the file but fail to pick up the metadata. If it turns out, in the long run, that a lot of devices store metadata in such a non-standard format, then we'll want to learn to read this type of non-standard metadata. Jiri, do you agree? |
|
|
A clarification of how tagging of WAVes should work: - reading: the plug-in should find the first LIST-INFO chunk, process all its sub-chunks and read all metadata from them. The plug-in could possibly try to find other LIST-INFO chunks then and do the same. - writing: the plug-in should prepare all metadata supplied by MM and check whether they fit the current LIST-INFO chunk present in the WAV file. If possible, it will only overwrite this chunk, if it isn't possible (new metadata occupy more space) a temporary file is needed where a new LIST-INFO chunk is created and all other chunks and simply copied from the original file. Note: the plug-in should preserve all LIST-INFO subchunks that it doesn't understand (doesn't read/write data to them). As for they WAV file from Rusty, I don't see any problem there. It contains LIST-INFO chunk in the begining (which should be processed as stated above), then LIST-exif chunk which we 'don't understand' and so we simply don't do anything with it (btw, it contains EXIF data that today almost every camera puts to JPEG files, seems that they are stored in WAV files as well now), then there's a 'data' chunk and that's all. |
|
|
OK no problem, but it will take more than two days :( Estimated time of finish Thurstday next week or maybe earlyer. |
|
|
We have major problem here. Ricoh Files You have sent are not created Correctly they have Junk at the end of file with which I do not know what to do (Truncate), file size is not reported/written correctly. Allthru all other things are fixed and it is ready for release. Note: even Sound forge CS has difficulty to determine track length, all other apps just ignores junk and do not plays it. |
|
|
Reminder sent to: rusty |
|
|
I suggest that as long as it works for most .wav files, and _doesn't choke_ on corrupt files, then it's fine. Note: Beta 1 is going out on Friday, so please send the code to Jiri if you guys agree it's ready for the build. |
|
|
Source of 1.0.1.123 Beta3 Version is Sent Jiri. I have tested on more than 200 Files and it passed. |
|
|
Reminder sent to: rusty |
|
|
Included in build 816. - I haven't had time to test the plug-in, hopefully it works well. |
|
|
Retested in 816, and the problem no longer occurs on the .wav files on which originally occured, however, it does occur on another .wav file that is included with Quicken (the most popular personal financial management application application here in NA). The file (qdelete3.wav) is posted to the ftp server. Question: I'm hoping that the solution can be implemented in such a manner that this kind of Freeze will _never_ happen even if the file format is completely messed up. Is this not possible? |
|
|
I have finished new version of F_WAVE (v1.0.2.134). I hope that this will be finaly good, I have tested it with 0001170:0003500, It filtered 0000025:0000040 Different Headers and Bad Metadata. So now it ignores bad Headers It just read Format Info, Fixes Bad position of Metadata chunk, Fix bad Data Stream on bad format Files like RIM00042.wav by appending lost bytes to Data stream, mark bad metadata as JUNK, Fixes wrong File Length, Not case sensitive Year tag format it supports all formats (US, EU, UK) instead of US only (Again bad Metadata format as according to riff Spec it is in US date format), and other minor optimization/speed things. |
|
|
Reminder sent to: rusty |
|
|
Tested v1.0.2.134 of the plugin with build 818, and all seems to work ok as far as scanning is concerned. Re-assigning to Jiri for inclusion. |
|
|
The latest sources compiled and included in build 819. |
|
|
Verified 820. |
