Author Topic: 16/24bit depth column  (Read 12450 times)

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
Audacity refers to MP3 and AAC files as "32-bit float." I suppose that's as accurate a description as any. But I really don't know if there's an industry standard. "Float" might be a good option, but I suspect the goal with this implementation is to keep the value down to two characters for nice, thin columns.

IMO CritterMan's suggestion above would be the most spot-on;  if a two-character designation is a must, perhaps either "FL" or "3F", if 3 characters then "32F" would be good.  ost I hear ya as far as seeing "Unknown bit depth" for every mp3/m4a being an eyesore.  Thanks Steven for leaving comments open.

ost

  • Jr. Member
  • **
  • Posts: 94
if a two-character designation is a must, perhaps either "FL" or "3F", if 3 characters then "32F" would be good.

100% agree  ;)

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
Technically, when compression takes place, the various lossy codecs discard the set bit depth and as part of their space saving algorithms, change them to variable bit depth.
So maybe VAR would be a suitable solution.
MusicBee and my library - Making bee-utiful music together

CritterMan

  • Sr. Member
  • ****
  • Posts: 556
  • Now with FiiO M11!
I can see why this feature was avoided for so long. Unknown would probably be too often confused for "something is wrong."

For me both mp3tag and foobar show nothing for lossy format files when the field is added to a column.
I think MB could do the same thing.

I agree with redwing. It shouldn't appear alongside files it doesn't apply to. But, to display nothing would probably also be seen as an error.

Bee-liever seems to have a good suggestion, but since so many users could have so many ideas of what it should be, I think perhaps some more complexity may be required:

-Choose a default behavior, maybe even 16.
-Provide an option to make it user-defineable, including blank so it could be ignored in formulas if not present.

Code
$IsNull(<Bit Depth>,,"Bit Depth: "<Bit Depth>)
Home Desk ~ MB 3.3 Portable • Questyle CMA400i (ASIO) • Sennheiser HD 660S (balanced) / Audeze EL-8 Closed Back / Fostex TR-X00 Ebony • Teac AI-101DA • Jamo C93 + Dayton Audio SUB-1000
Work Desk ~ MB 3.3 Portable / Tidal • SMSL SU-8 v2 • Nobsound NS-05P • THX AAA 789 • Sennheiser HD 58X (balanced)
OTG ~ FiiO M11 • Audiofly AF180 / B&O H6

frankz

  • Sr. Member
  • ****
  • Posts: 3834
I'll not use the data column so I'm not sure my opinion counts for much here, but 16-bit is the generally accepted linguistic shortcut for mp3 files.  People are going to expect that they are 16 bit because that's what they've always been referred to as (16/44.1).  So I agree that showing 16-bit, while maybe not technically correct, is traditionally correct.

By the way, Audacity opens files for editing in 32 bit float as a default. It's not a reflection of the bit depth of the file itself, it's the mode in which Audacity is allowing the file to be edited for minimum dynamic range loss.  Bit depth is related to dynamic range. Sample rate is related to frequencies.  That's why no human being can detect the difference between 16 bit and 24 bit without deafening themselves in the process (you'd need to turn it up inhumanly loud for the difference to reveal itself), but a handful of human beings (that can hear above 20,000) can tell the difference between 44.1khz and 96khz.
Last Edit: April 02, 2018, 12:27:41 AM by frankz

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
For me both mp3tag and foobar show nothing for lossy format files when the field is added to a column.
I think MB could do the same thing.

This is what I had when using a custom tag and Mp3tag to write the value.
Since MB is automatically populating the field on file import, maybe the best outcome would be;
1/:  "Unknown" for any older unscanned files
2/:  Bit Depth for lossless formats
3/:  Leave it blank for lossy formats with the tooltip; "Only lossless formats have fixed bit depth"
MusicBee and my library - Making bee-utiful music together

redwing

  • Guest
I'm not sure what all the fuss is about.

I think that "16 bit" looks better than "Unknown Bit Depth" even if it's not correct.

Are you using a virtual tag for the field in the column since that's the only place I can see "Unknown Bit Depth" and it's blank everywhere else?
If you want to see blank rather than "Unknown Bit Depth", use this code in place of <Bit Depth>.
Code
$IsNull(<Bit Depth>,,<Bit Depth>)
Also if you prefer to see 16 (or whatever) instead for all files with the field blank, use this.
Code
$IsNull(<Bit Depth>,16,<Bit Depth>)

for the next update i have changed it to show blank for lossy files.

AAC files still show 16.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
AAC files still show 16.
only if MB thinks its an ALAC file. Is it the same if you rescan it?

redwing

  • Guest

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
would you mind sending me a link to the file? I have a lot of aac files and they work fine


Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
Hmm, before last update all my mp3 and m4a files was showing correct bit depth - 16 bit. Now it's Unknown Bit Depth  :-\
are you using the field in a virtual tag, or can you explain how you are using the field?

ost

  • Jr. Member
  • **
  • Posts: 94
Hmm, before last update all my mp3 and m4a files was showing correct bit depth - 16 bit. Now it's Unknown Bit Depth  :-\
are you using the field in a virtual tag, or can you explain how you are using the field?

Virtual tag: {font: Amazon Ember;Italic;8}<.Ext> · <Sample Rate>·<Bit Depth> bit

After redwing advice I changed it to {font: Amazon Ember;Italic;8}<.Ext> · <Sample Rate>·$IsNull(<Bit Depth>,16,<Bit Depth>) bit and everything is fine.

redwing

  • Guest
would you mind sending me a link to the file?

PMed an iTunes-purchased one.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
PMed an iTunes-purchased one.
yes i get the same and its fixed for the next update