View Issue Details

IDProjectCategoryView StatusLast Update
0000601OpenMPTGeneralpublic2014-12-03 21:44
ReporterSaga Musix Assigned ToSaga Musix  
PriorityhighSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionOpenMPT 1.24.00.* (old testing) 
Target VersionOpenMPT 1.24.01.00 / libopenmpt 0.2-beta8 (upgrade first)Fixed in VersionOpenMPT 1.24.01.00 / libopenmpt 0.2-beta8 (upgrade first) 
Summary0000601: Design decision needed to prevent inconsistent auto-normalize with on-disk samples
Description

Right now, OpenMPT automatically normalizes samples (in some formats, e.g. FLAC is not a problem) with a resolution higher than 16-bit.
This may conflict with on-disk samples in the MPTM format, because in that mode, samples are never auto-noramlized on load.

In order to be able to give a consistent user experience, we need to have a design decision until the final release of OpenMPT 1.24.01.00:

  • Either remove auto-normalization on 16-bit conversion completely, which will of course lead to an increased SQNR for these samples when normalizing them afterwards
  • Support for higher-quality samples (e.g. 32-bit integer or float) in the mixer. This is probably the preferrable solution.
TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

FreezeFlame

FreezeFlame

2014-11-02 19:59

reporter   ~0001826

Im for the included support of 24,32 bit samples.

Saga Musix

Saga Musix

2014-11-02 20:47

administrator   ~0001827

Obviously that's the long-term solution that everyone wants, however the design decision needed here is if we need to jump through these hoops or if there is another acceptabe short-term solution for the 1.24 release. And no, you don't need to answer that question, this ticket was not created to gather user opinions.

FreezeFlame

FreezeFlame

2014-11-02 23:21

reporter   ~0001828

Last edited: 2014-11-02 23:22

In this case, sorry.

But it woudn't be an bad idea if the first idea is considered that OpenMPT lets the user chose if he/she wants the file normalized or not and then creates an temporary copy (similiar to how virtual memory works) that is getting edited instead of the original file on the harddrive. The user can chose whenever the original file can be overwriten (if changes were made at all), or an copy is made from the temporary file and the links point to it instead of the original file.

Might work and solve that tricky problem you're describing :).
And i hope there is finaly gonna be 24,32bit sample support for real.

Saga Musix

Saga Musix

2014-12-03 21:44

administrator   ~0001859

For now, an alternative short-term solution has been introduced in r4633: When a sample gets normalized upon loading, the "sample modified" flag is being set automatically. This way, the user is prompted to save the changes when closing the module anyway.

Issue History

Date Modified Username Field Change
2014-11-02 01:27 Saga Musix New Issue
2014-11-02 19:59 FreezeFlame Note Added: 0001826
2014-11-02 20:47 Saga Musix Note Added: 0001827
2014-11-02 23:21 FreezeFlame Note Added: 0001828
2014-11-02 23:21 FreezeFlame Note Edited: 0001828
2014-11-02 23:22 FreezeFlame Note Edited: 0001828
2014-11-02 23:22 FreezeFlame Note Edited: 0001828
2014-12-03 21:44 Saga Musix Note Added: 0001859
2014-12-03 21:44 Saga Musix Assigned To => Saga Musix
2014-12-03 21:44 Saga Musix Status new => resolved
2014-12-03 21:44 Saga Musix Resolution open => fixed
2014-12-03 21:44 Saga Musix Fixed in Version => OpenMPT 1.24.01.00 / libopenmpt 0.2-beta8 (upgrade first)