IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Why is dBpoweramp reporting 16 bits as the resolution for mp3?, Mp3 audio data is 32-bit float.
soundping
post Sep 2 2013, 21:26
Post #1





Group: Members
Posts: 36
Joined: 3-February 12
Member No.: 96900



MODERATION:
Split from this topic:
http://www.hydrogenaudio.org/forums/index....st&p=843535

It wasn't foobar. It was properties.
http://www.imagebam.com/image/cebd9e273703869

This post has been edited by greynol: Sep 3 2013, 03:42
Reason for edit: Added context to topic split.
Go to the top of the page
+Quote Post
greynol
post Sep 2 2013, 21:35
Post #2





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Your software is wrong. The depth of an MP3-encoded file is 32-bit float.

Maybe spoon would like to provide an explanation.

This post has been edited by greynol: Sep 2 2013, 21:41


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Sep 4 2013, 14:49
Post #3


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2725
Joined: 24-March 02
Member No.: 1615



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...


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
db1989
post Sep 4 2013, 14:59
Post #4





Group: Super Moderator
Posts: 5174
Joined: 23-June 06
Member No.: 32180



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).
Go to the top of the page
+Quote Post
greynol
post Sep 4 2013, 17:29
Post #5





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
saratoga
post Sep 4 2013, 17:34
Post #6





Group: Members
Posts: 4718
Joined: 2-September 02
Member No.: 3264



It would probably be more clear if that field was removed for transform codecs because its not really meaningful.
Go to the top of the page
+Quote Post
greynol
post Sep 4 2013, 17:39
Post #7





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



It's assuming all you would ever do with an MP3 file is decode it with dBpoweramp which is absurd.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
db1989
post Sep 4 2013, 17:47
Post #8





Group: Super Moderator
Posts: 5174
Joined: 23-June 06
Member No.: 32180



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.
Go to the top of the page
+Quote Post
greynol
post Sep 4 2013, 17:56
Post #9





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Sep 4 2013, 20:12


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
AndyH-ha
post Sep 4 2013, 21:39
Post #10





Group: Members
Posts: 2192
Joined: 31-August 05
Member No.: 24222



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.
Go to the top of the page
+Quote Post
spoon
post Sep 4 2013, 22:35
Post #11


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2725
Joined: 24-March 02
Member No.: 1615



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.

This post has been edited by spoon: Sep 4 2013, 22:36


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
saratoga
post Sep 4 2013, 22:41
Post #12





Group: Members
Posts: 4718
Joined: 2-September 02
Member No.: 3264



QUOTE (AndyH-ha @ Sep 4 2013, 16:39) *
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.

QUOTE (spoon @ Sep 4 2013, 17:35) *
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".
Go to the top of the page
+Quote Post
db1989
post Sep 4 2013, 22:42
Post #13





Group: Super Moderator
Posts: 5174
Joined: 23-June 06
Member No.: 32180



QUOTE (spoon @ Sep 4 2013, 22:35) *
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 itll either drink or open a few hundred threads here asking where all the fluids have gone.
Go to the top of the page
+Quote Post
Martel
post Sep 5 2013, 18:04
Post #14





Group: Members
Posts: 535
Joined: 31-May 04
From: Czech Rep.
Member No.: 14430



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. smile.gif

This post has been edited by Martel: Sep 5 2013, 18:06


--------------------
IE4 Rockbox Clip+ AAC@192; HD 668B/HD 518 Xonar DX FB2k FLAC;
Go to the top of the page
+Quote Post
db1989
post Sep 5 2013, 18:06
Post #15





Group: Super Moderator
Posts: 5174
Joined: 23-June 06
Member No.: 32180



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.

This post has been edited by db1989: Sep 5 2013, 18:09
Go to the top of the page
+Quote Post
greynol
post Sep 5 2013, 18:21
Post #16





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Martel @ Sep 5 2013, 10:04) *
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. smile.gif

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.

This post has been edited by greynol: Sep 5 2013, 18:22


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th April 2014 - 02:50