View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015640 | MM5 Codec Pack | General | public | 2019-05-05 01:30 | 2020-03-27 01:11 |
| Reporter | peke | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0015640: M4A: M4A files with Id3 tag fail to play and crash MM | ||||
| Description | Some M4A tracks asre not playable due the fact that they have id3v2.x and id3v1.1 written in M4A braking standard and render them corrupted. NOTE: I have not being able to replicate user Crash when codec is installed but I can confirm it fail to play. Expected that ID3v2.x is skipped during playback and that tag write result either in fail or silently skipped. These files can be Automatically fixed by removing id3 tag from file if after id3 file is detected as "ftypM4A" and have extension of M4A (Confirmed by manually removed id3v2.3 from beginning of sample file and id3v1.1 from file end). | ||||
| Additional Information | TICKET ID: LLE-351-47650 Sample files supplied. TPK-436-65118 Another report, but more severe corruption | ||||
| Tags | No tags attached. | ||||
|
|
These files user has cannot be automatically fixed so easily, as there are more things wrong. Not only ID3 tag written incorrectly to M4A, this ID3 tag has also incorrect size written, so parser cannot find the end correctly. And searching through the file just because "what if there is ftyp somewhere" could cause other problems. Decoder in fact tries to play it as AAC, but this fails, because it is not pure AAC. I cannot reproduce the crash, so cannot look, why it happened, for me it correctly fails. |
|
|
Fixed in MM5 codec pack 3.0.1, merged to MM4 codec pack 2.3.107. Used better detection of such corruption and avoid decoding and tagging, where detected. |
|
|
As pointed by you offline: "M4A file contains index to data in moov header, inserting ID3 moves data without reindexing, so no wonder, that it cannot be played" is your fix include ability to try to decode and play such files or just skip them. It could be very useful if files can be played only while tagging such files will be disabled? Maybe even common dialog about fail "File structure is corrupted tag isn't saved to prevent further degradation" as a part of Jiri proposal at 0011179:0052800 |
|
|
Sure it'd be nice to allow such files to play in MM, but it's really not a priority--it's more important that whatever app introduces the buggy tags be fixed. That said, I agree that there should be some sort of standard messaging that appears in cases where: a) user can't tag a file because it's corrupted. e.g. 'Tag update failed: <Filename> is corrupted.' b) user can't play a file because it's corrupted. e.g. File would turn grey and a toast message appears transiently indicating 'Playback failed: <filename> is corrupted.' Probably not the highest priority though. This should probably be tracked in an MM5 bug, though, since the original issue has been fixed. |
