View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014449 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2017-10-07 21:51 | 2024-07-15 06:41 |
| Reporter | peke | Assigned To | |||
| Priority | high | Severity | tweak | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Target Version | 5.2 | Fixed in Version | 5.0 | ||
| Summary | 0014449: BPM: BPM should be shown with Two decimals | ||||
| Description | BPM should be shown with Two decimals like all other apps. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2116 | ||||
|
|
Is there any significant request for this feature? As I see, ID3v2 specs this as integer, so we'd either have to not follow the specs or introduce an inconsistency between the DB and tags. That said, if it's necessary, we certainly can do it. The field is declared as integer in the DB, but SQLite should let us to store floats anyway. |
|
|
We currently limit BPM to max 999. I would remove this restriction and allow values till 32767. So it can be saved to standard tags, and other apps can interpret them with decimal point. But I wouldn't show decimal point in our UI, there should be what is really saved in tags I think, as it is not standard and could be confusing. |
|
|
999 limit changed to 32767 in build 2116. Resolving, I think it should be enough. Displaying 2525 as 25.25 in views can be added e.g. by simple script (only change needed is in trackListView_add.js, object uitools.tracklistFieldDefs.bpm). |
|
|
Verified 2116 |
|
|
Returning from 0020949, Mixxx calculates BPM with 2 decimal accuracy, which MediaMonkey overwrites when any tag changes are made to the files. |
|
|
Note - it is because FLAC stores this value as string and can save there anything. But we handle it as integer, so cannot keep the original value. But arguments can still be the same, it is not standard and cannot be stored to other formats anyway... |
|
|
I think that we could implement the following (discussed with Michal): 1. Internally store BPM as float. 2. Store floats wherever possible (e.g. flac). 3. Store integers as is in id3, store floats as x100. 4. BPM>=1000 from ID3 would be read as /100. Michal possibly prefers 3&4 to be optional, I think that it's hardly anytime necessary to make this configurable. A notable exception might be is flac with float bpm is converted to id3. That probably more useful would be an addon that resets fractional part of bpm in id3 tags. This way e.g. 12345 would be converted to 123. Planned as MM2025 feature. |
