MODERATION:
Split from this topic:
http://www.hydrogenaudio.org/forums/index....st&p=843535 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=102440&view=findpost&p=843535)
It wasn't foobar. It was properties.
http://www.imagebam.com/image/cebd9e273703869 (http://www.imagebam.com/image/cebd9e273703869)
Your software is wrong. The depth of an MP3-encoded file is 32-bit float.
Maybe spoon would like to provide an explanation.
In dBpoweramp it reports what it decodes to, by default mp3 decode to 16 bit. You can change in dBpoweramp Configuration >> Codecs >> Advanced 'Mp3 decode to' 32 bit float, then dBpoweramp will report all your mp3s as 32 bit float...
I think that is very illogical and misleading behaviour when properties are being viewed in any context except playback itself (such as the status bar of a player).
The reason this discussion exists is proof that someone has been misled. I would not have made a stink about it if erroneous information hadn't been presented as if it were valid experimental data.
It would probably be more clear if that field was removed for transform codecs because its not really meaningful.
It's assuming all you would ever do with an MP3 file is decode it with dBpoweramp which is absurd.
Presenting something that is context-specific to/dependent upon dBpowerAMP as if it were an intrinsic property of a file, especially when mixed amongst other data that conversely do meet the latter description, is irresponsible. Some might even call it hubris.
The OP called it "properties" FFS.
16 bits is not a property of an MP3 file.
I'll reserve calling it hubris in the event the item isn't removed from the property sheet.
The audio data from which the mp3 was created has some particular resolution. Most often that is 16 bit. Converting the file to some compressed format, lossy or lossless, cannot increase the bit depth of the audio data. As far as the audio is concerned, the format, 32 bit float, or any other, is irrelevant information. It will not make any difference to what comes from the speakers.
Converting to a higher bit depth can of course be important in some circumstances, for instance to decrease quantization errors when making extensive modifications to the data. There is probably an important reason it is used in mp3, i.e. it is probably the way to optimize quality and reduce storage requirements. Someone intending to write code to do something with the encoded files needs to know the format details, but it is still irrelevant, and not true information about the audio, to any user. Any display which purports to be about the audio should provide the true audio bit depth, not the format specs.
The irony is...we can change this to report the bit depth as "", which will please the well educated people of this forum, however it will create confusion with average joe I am sure, who will encode a CD to mp3 then wonder why it is not reporting a bit depth.
Sometimes doing the right thing, is not doing the right thing (after 10 years we gave in and default Vorbis Comments: comment & conductor are no longer mapped to the values as set by 'the standard', the number of complaints about this since the change: 1 in the last year...number of complaints about following the official standard by mapping previously, perhaps 100).
I am willing to try to do the right thing here, as an experiment.
The audio data from which the mp3 was created has some particular resolution. Most often that is 16 bit. Converting the file to some compressed format, lossy or lossless, cannot increase the bit depth of the audio data.
Yeah but you have no way to know what the source was.
The irony is...we can change this to report the bit depth as "", which will please the well educated people of this forum, however it will create confusion with average joe I am sure, who will encode a CD to mp3 then wonder why it is not reporting a bit depth.
I would just say "lossy".
The irony is...we can change this to report the bit depth as "", which will please the well educated people of this forum, however it will create confusion with average joe I am sure, who will encode a CD to mp3 then wonder why it is not reporting a bit depth.
So put ‘N/A’. You can even make it into a hyperlink to a page explaining why MP3 does not have a bit-depth. Educating people is infinitely better than inserting false information from nowhere simply so they can avoid being confused by the fact that not everything in the world works in the same way.
Lead the horse to water, and it’ll either drink or open a few hundred threads here asking where all the fluids have gone.
Isn't the SW commercial? In that case, the right thing to do is what majority of paying customers want/expect, no matter how incorrect it is academically. Or do the "academic" change in the free version only.
I suspect that’s a completely moot point when the majority of said customers probably have no idea what they want/expect because they don’t understand the technical basis. Chances are they won’t want or expect anything until they don’t see a bit-depth and then get confused.
So, what, Illustrate would be right to continue inserting spurious data that reflects only the current setting of their program, while presenting it as an inherent trait of the file, because it would help the world to seem simpler to people who don’t understand lossy formats?
Besides, commercialism and truth are not actually mutually exclusive, despite the many suggestions otherwise in practice.
In that case, the right thing to do is what majority of paying customers want/expect, no matter how incorrect it is academically. Or do the "academic" change in the free version only.
That has got to be about the dumbest thing I've read in weeks.
I could spend the entire day posting examples of things people get that they don't expect for which they happily pay that affects them in adverse ways.
Yes, let the market decide. Writing a few lines of code is simply not cost efficient.