View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006513 | MMW v4 | Framework: Tagging | public | 2010-09-29 14:59 | 2010-10-20 03:51 |
Reporter | Ludek | Assigned To | |||
Priority | urgent | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | no change required | ||
Summary | 0006513: MP3 tagging: Encoder is stored to wrong tag field | ||||
Description | During debugging 0006499 I found that we write/read encoder to the ID3v2 field: { TSSE } ID3FID_ENCODERSETTINGS, //< Software/Hardware and settings used for encoding */ but the other apps like iTunes stores it to the field: { TENC } ID3FID_ENCODEDBY, //< Encoded by */ Shouldn't we change this to be compatible? | ||||
Tags | No tags attached. | ||||
Fixed in build | |||||
|
Assign to me for fix (if you agree). |
|
I don't know whether any other software does it differently, but I think that we do it absolutely right, given description of these frames from ID3.org: TSSE The 'Software/Hardware and settings used for encoding' frame includes the used audio encoder and its settings when the file was encoded. Hardware refers to hardware encoders, not the computer on which a program was run. TENC The 'Encoded by' frame contains the name of the person or organisation that encoded the audio file. This field may contain a copyright message, if the audio file also is copyrighted by the encoder. So, I don't think we should do anything about it. |
|
Hmmm, I would expect the Encoder field in MediaMonkey to show "Encoded by" info rather than "encoder settings" i.e. for sample file including fields TENC: iTunes 6.0.3 TSSE: Variable Bit Rate 269 kbps I would expect MM to show "iTunes 6.0.3" instead fo "Variable Bit Rate 269 kbps". Maybe we could somehow concatenate the values to the Encoder field? But this is probably a low priority issue. |
|
I think that ID3.org description is pretty clear - TENC is for _person_, while TSSE is both for software and its settings. I.e., iTunes filled in values are clearly wrong. We could consider some changes, but only in case we find out the more applications take this (incorrect) approach. |