Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Retrieving Lame header data or Xing header in Delphi (Read 1789 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Retrieving Lame header data or Xing header in Delphi

hi guys,

I'm doing a little program to check all my mp3s and report the old ones i want to update with better encondings.
As my library started 20 years ago, i know many of these needes reriping or just updating to higher bitrateds or reencoded with
newer lame.

Currently i am coding in Delphi, using mp3fileutils v0.6a, and recursive scanning my library getting bitrates, sizes, etc...
Bitrate from mpeginfo is getting ok. So i can filter by low bitrates (anything <192 for example) and update those mp3s.

But then i thought about  very old encodes, for example my rip from Bjork-Homogenic must be 15 years ago or more, using encSpot i got this:
>Encoder             : FhG (fastenc or mp3enc)

This is the information i want to retrieve.
Any hints on how can i do this?
The library i am using is able to do some things, maybe i can use them to retrieve this info.

June 2011: v0.5b -> v0.6
  ========================
  New features
    - Private Frames
    - VBRI-Header-Detection
    - added some more genres to the Genres-List
    - added methods GetUserText, SetUserText, GetAllUserTextFrames,
      deleted TXXX-Frames from GetAllTextFrames

Thanks!

Edit: i plan to add some kind of sanitation tests, as all files in the same folder must have the same album, check for not missing tracks (if last one is 19, it must be 19files), etc...

Thanks!



Re: Retrieving Lame header data or Xing header in Delphi

Reply #1 –
The functionality of encspot or other software like that was based on guessing the codec based on the options (joint stereo, bit reservoir...) and content of the encoded files, and only in case of LAME, the version was actually read from the file as I was written by the encoder to the file.

As such, you will not be able to read which encoder generated the file (except the case of LAME).

Back in the day, aside of encspot, there were a few other programs that checked the file to determine if it had errors in it (problems with the download).  Nowadays, probably you can use foobar2000  with the file integrity verifier compoment.

Re: Retrieving Lame header data or Xing header in Delphi

Reply #2 –
Maybe you can incorporate mp3guessenc command-line tool in your project, or study encoder detection from the source code.

Re: Retrieving Lame header data or Xing header in Delphi

Reply #3 –
Most likely anything old enough to not have a lame header isn't worth keeping. I would check that and not worry about other things.

Re: Retrieving Lame header data or Xing header in Delphi

Reply #4 –
Hey thanks everyone for suggestions!
I remembered that encspot (still use de commandline today) was some kind of heuristics.
I'll check the lame header
Thanks!
 

Re: Retrieving Lame header data or Xing header in Delphi

Reply #5 –
Quote
or just updating to higher bitrateds or reencoded with
newer lame

Don't do that.

That,  what was getting lost during the original encoding, is gone forever. There is no way to bring it back. That is, why MP3 is a lossy format.

Re-encoding existing MP3 files with more recent encoders or higher bit rates doesn't bring it back.  ;)

If you re-encode, you will get another layer of quality loss on top of the original loss. Re-encoding MP3 always leads to quality degration, especially, if different codec than the original one is used.

The only way to increase the quality is to re-rip from the lossless CD source.  :D

In my opinion, your approach of examining headers or bitrates to find out the quality, is unreliable:
If you've encoded a MP3 by yourself, you may know, which encoder you used for that.
If you didn't encode a MP3 by yourself,  you may find out, which encoder was used, BUT NOT, if the source was lossless or a crappy 96kbps Blade encoding.  :P

I would try to automate the examination of the frequency spectrum for missing frequency ranges instead.
Low-quality-MP3 have a huge amount of high-frequency loss and a heavily fragmented high frequency range. The spectogram looks blocky in the high frequency range. That blockieness is, what you hear as "shlllrlllsshshsllscsll..."-noise during playback of low-bitrate MP3.
- I abandoned this account since I didn't find a way to delete it -