View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012840 | MMW v4 | Codec | public | 2015-09-02 01:05 | 2016-05-24 17:57 |
| Reporter | peke | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | unable to reproduce |
| Status | assigned | Resolution | open | ||
| Product Version | 4.1.8 | ||||
| Summary | 0012840: F_FLAC: Flac file gets corrupted after Albm art Add | ||||
| Description | There was some reports that files got corrupted after tagging. I can confirm that physical samples provided by user are indeed really corrupted and playing incorrectly. I also noted that volume is not right on one that is corrupted like it is not same file. | ||||
| Additional Information | CAR-393-19234 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I've analyzed the corrupted file and the log. It seems, there is something strange with the user's computer (RAM or HDD). Corrupted file has all metadata correctly written and has right size. The most of the audio data is ok, but there are blocks of nulls in the file instead of some source audio data. E.g. cca 500kB is ok, then 2263B of nulls, then cca 120kB ok, than 2927B of nulls, etc. These nulls make the bugs in the audio playback. During FLAC tagging, we make a copy of audio data from the source file to the destination file (in this case, where there is not enough space in the file header for new metadata), this is made by reading data from TFileStream and writing them immediately to another TFileStream, nothing between, no place, where we could "make these zeros". I think, there could be some HW issue. Peke, please, try to discuss it with the user, do some HW tests. I have no idea, where else could be the problem. |
|
|
I canme to same conclusion like you. If you remember I was one that was wrote original f_FLAC and was using same approach (but more crude, slower and bloated). I'll see if I can arrange remote session with User to confirm our both suspicions. Only thing I can think of is taht we do another layer of checks where we will use some sort of fingerprinting/CRC check on File audio stream data prior to rename. Thus that is why we use .xxxxxx file at first place. I'm thinking that this is not MMW issue, you? |
|
|
Fingerprinting would slow things down. And in case the original file is incorrectly read, it wouldn't detect any problem (it would compare wrong data against the same wrong data). Yes, it does not seem to be MMW issue, we will see, what you will find out. User could also try to switch off all additional scripts and autoorganize function and try without them. |
|
|
I'll do your suggestions as soon as User gets back in 6 weeks. eg. I usually install latest MMW beta as portable and then test to avoid any conflicts with existing plugins. |
