OK, here is a little something I hacked together during the weekend. I just got tired waiting for an EncSpot replacement, so I thought I might as well start one myself.
Basically, all I wanted was a tool that would show me the average bitrate of a folder after I rip an album and the encoder settings used. It should work pretty well for most files, except for non Lame encoded mp3 files. The non Lame encoder mp3 detection is not as accurate as EncSpot, but for Lame encoded files it should work pretty well because it uses phwip's Lame Tag reading code so it can guess the encoding settings/preset used.

Okay, what else... Oh, no shell integration yet, but you can pass a file from the commandline and it will open the directory where the file is located. So you can place a shortcut on the desktop and drop a file on it, or call it from the "Open with" right click menu.
Sources are included, so you are welcome to add whatever you want
Enough talk, better you try it yourself, hopefully you like it.

Download:
http://www.apehaus.com/burrrn/mrquestionman01.rar

Greets, Gambit

P.S.: We can still talk about the name, it's not final

Nice start indeed!
perhaps you should have a look at the discussion here if you are interested in a more accurate guessing program:
http://www.hydrogenaudio.org/forums/index....wtopic=11785&hl

My Grandmama Loves Mr QuestionMan !!!

This tool display the Encoder Version & Setting of OGG-MPC-APE-FLAC (Only Encoder for FLAC due to the great profiles we have for flac ...)

... no more massive boring open/right click/file info to display the info from gigs of MPC ! ... specially great to be sure all songs from an MPC rip are all at the same setting ...
Thanks a lot ! Personnaly I am gonna use it for MPC a bit like I use VorbisExt for Ogg !

Hope the tool gets even better !!! specially in the MP3/Encspot Like area even if I don't use MP3

Another nice tool, Gambit!
Thanks for your work.

Nice try really.Did few tests and it guessed accurately
Anyway a bit o/t but somebody know of some plugin for foobar which can do same as enc-spot or this nice app for guesing mp3s as foobar is already accurate and gives all info about other audio files formats.

mp4 support ?

Wonderful, this is right what I've been looking for a long time. Thanks for your efforts!

Additional features like reporting (html, csv ..), extended info and .. well .. basically everything that MAC 2.92 offers would be great. So .. since MAC is now open source as well, I would _love_ to see those two married - if that is possible (I've just seen in MrQuestionman's source that you have taken some tables from Jürgen Faul).

However, keep up the good work!

Sven

Really nice app!

one curious question: Do you plan command-line version (I got used to encspot command-line version

thx gambit, really nice program

I saw that, I even mailed and PMed Feltzkrone and because he did not respond I decided to go ahead on my own.


No.

I like the 'No shit!' button.

This is great.

One small request: when I am viewing an mp3 file the Encoder Info doesn't all fit in that column, and I don't have enough screen space to expand the column. This is no problem of course, because when I hold the mouse over there it pops up with a tooltip displaying the contents of this box. However, the tooltip is aligned with the box underneath it, so on my PC I can't see all of the text in this either because it goes off the right hand edge of the screen. Is there any chance you could make the tooltips right-align with the right hand edge of the screen if they are wide enough that they would otherwise go off-screen?

Bug report: if you switch between directories quite quickly, then you can get an "array index out of bounds" error. (Maybe this is not the exact name).

This is probably when you choose a directory which has less entries than the actual one, and the entries for the actual were not yet calculated, so the prog tries to do it for the new dir. (MAYBE)

Great app, though

BTW, why does it give e.g. "preset-standard (guess)" and "not stored"? In the second case QuestionMan can't even guess, while in the first it can?

Is MrAnwerMan's (Edit: Mr QuestionMan ... dyslexia strikes again) readout of Lame settings used contingent on the version of Lame used? The only thing it's showing after the Lame version in the 'Encoder Info' column for my library of 3.90.3 encoded MP3s is: '<not stored>'

Also, Mr QuestionMan doesn't access other drives on a network via Windows' Network Neighborhood.

It's also not reporting bitrates accurately for FhG (fastenc) MP3s. I'm seeing all 32kbps bitrates for VBR encoded files that EncSpot reports a range of averages from 130kbps to 146kbps.

Great concept! Wish it'd work for me.

It would be great if you could add the option to parse subdirectories. I'm really curious about the average bitrate of all my music.

Wow this tool looks great.

Very fast too, much faster than EncSpot, I think.

(Where's the "No Shit" button?)

About box.

very nice, i like, fast scanning

Amazing! I tested my Samples folder, which countains Tool - Schism in wav and encoded in:

Ogg Vorbis (GT3b1) -q6
LAME 3.90.3 @ --alt-preset standard
WMA Lossless (which it couldn't detect)
WMA Pro @ Some stupid setting . . . I think 98% VBR or whatever M$ calls it
PsyTEL AAC
Monkey's Audio @ Extra High
FLAC @ -q8
Musepack 1.14 @ --quality 5
Nero AAC (Transparent LC and Streaming HE)
OptimFROG @ bestnew
and WavPack @ I don't remember (probably the highest ratio that isn't stupidly high)

The only encoders it couldn't guess were WMA lossless and Nero AAC (I guess it can't read MPEG4 containers yet) And the only encoders it didn't get settings for were WMA Pro, Psytel AAC (although it got LC), FLAC, and WavPack. Excellent app Gambit.

P.S. I like the "Shame on you for using WMA files!" message

edit: typos

great app - many thanks gambit

I really like the no-bs interface, only showing the most important info, contrary to lametag which i used before but with which i always had to search for the interesting stuff inside all of the data-overkill.

I understand that this is a very early version. However, the encoder-guessing doesn't seem to be very accurate:
For example, i ripped an album with EAC and LAME 3.96beta preset standard. Its an album which is very difficult to encode, and where glitches in gapless playback are easy to spot - so, i encountered two tracks where there were "clicks" during trackchanges - i used foobar to "fix" them manually. By doing that, the lame-header got removed i think.
Now to the important part. Encspot detects those two tracks as LAME 3.96beta, and the other ones as LAME 3.96.
Your programm instead detects the two "fixed" tracks as XING, and the others correctly as LAME 3.96b.

I would say, the guessing needs some work(not suprisingly, its an early version) - if it isn't very sure what codec it is, it should state "unable to guess", instead of doing risky guesses.

- Lyx

edit: hmm, probably the only data-type i miss is the used stereo-mode.

Settings are not saved yet, that will be added later. So then everybody can set the columns width the way they want (and fits their screen).


Yup, that's correct, but it's fixed already.


Well, if it shows '<not stored>' then the info is not there. Or, it's a bug in phwip's code and then you have to blame him


Yeah, that's broken right now, will be fixed. But if you have a shortcut on the desktop, you can acces it via that.


You have to fix your headers.


Yeah, that's a good idea.


I'm pretty sure foobar shouldn't remove the Lame Tag. If it does, well it shouldn't , maybe it's a foobar bug, gotta ask Peter about it.
As far as the mp3 detection goes... I really wish Feltzkrone would get involved. Feltzkrone, if you read this, please let us know what's up with you!

I do too. His program looked very promising. But he seems not to have posted here since beginning of march.

Why should we fix the headers for VBR files created by Fraunhofer encoders? There IS an official VBRI SDK out there!

Okay... RazorLame encoded MP3s are showing the data, but most of my library is ripped from CDs with EAC. Admittedly I'm, not very tech-savvy. I can't seem to find an EAC setting to tweak for fixing this. Could someone help me there?


Hmmm... MrAnwerMan doesn't seem to list anything on the desktop of the system it's running from. But but I can either boot the program from the remote systems via a link through the network, or just copy the small program file to the other systems.


I see that here:

http://www.iis.fraunhofer.de/amm/download/mp3_vbr_sdk.zip

But those files are the code, and again, I'm not really familiar with the technical end of these things. I'll see if I can figure out how to go about that process of fixing the headers as Gambit suggests .

Thanks for any tips you folks might be able to pass on.

Are you sure you use an encoder which writes the Lame Tag (newer builds of 3.90.3 and 3.92 and above, IIRC)?

Hi Gambit,

Thanks for your work!

It's quick, easy, happy program.


Rgds,
Johnson.

The LAME tag was introduced with LAME v3.90, but the "preset used" field was not used until v3.93, and later incorporated in the modified version of 3.90.3, I believe in a compile dated 12-Oct-2003. So if your version of LAME is older than that, or is 3.90.3 from somewhere other than RareWares, then it won't store the preset used.

When I ran this, it found a wma file in the directory. The display read something like "shame on you for having a wma file on your computer." I thought I would fall out of my chair laughing.

Yes... I've only used Lame for nearly 2 years at this point. Not having delved very deeply into the technical end of things, I had been using 3.92 up to last fall when I discovered that v3.90.1 was the recommended build. I had pretty much stuck with 3.90.1 until recently when I discovered specific uses for some newer versions.


Hey GetI!

Checking my v3.90.1, the date of lame.exe is 6/4/03. So after reading your comments, I downloaded the latest recommended compile of v3.90.1 posted here dated 2.6.04. But it still doesn't write the Lame settings to the MP3 file.

At this point I've archived Lame versions 3.90.1 (6/4/03), 3.90.1 (2.6.04), 3.91, 3.92, 3.93.1, 3.95.1 and 3.96b1. I did a test compressing a test wav with each for the two settings I most frequently use: '--alt-preset standard' and '--alt-preset 128'

For the versions 3.90.1 (6/4/03), 3.90.1 (2.6.04), 3.91, 3.92 >not writing< compression settings to the MP3s, Mr QuestionMan reported compression settings accurately for files compressed with '--alt-preset standard', and added '(guessed)' after the setting. But files compressed at '--alt-preset 128', Mr QuestionMan reported '(not stored)'.

For the versions 3.93.1, 3.95.1 and 3.96b1 >writing< compression settings to the MP3s, Mr QuestionMan reported both compression settings accurately.

Lame version ********** Mr QuestionMan compression report:
-------------------------------------------------------------------------

3.90.3 (6/4/03) ********** (alt-)preset standard (guessed)
3.90.3 (6/4/03) ********** (not stored)
3.90.3 (2/6/04) ********** (alt-)preset standard (guessed)
3.90.3 (2/6/04) ********** (not stored)
3.91 ********** (alt-)preset standard (guessed)
3.91 ********** (not stored)
3.92 ********** (alt-)preset standard (guessed)
3.92 ********** (not stored)
3.93.1 ********** V2: preset standard
3.93.1 ********** 128
3.95.1 ********** V2: preset standard
3.95.1 ********** 128
3.96b1 ********** V2: preset standard
3.96b1 ********** 128

-------------------------------------------------------------------------

Interesting the switch from reporting '(alt-)preset standard' on earlier compiles when 'guessing', to 'V2: preset standard' on the later ones. And the abr 128 files just reported as '128' and not 'V2: preset 128' on later compiles.

Why 'V2: preset standard' and not '--alt-preset standard'?

Okay Gambit... I tracked down how to do this with FB2k, downloaded it, and gave it a try. Running the option to fix headers ended up with the bitrates for FhG VBR encoded MP3s being reported correctly. But now Mr QuestionMan reports the encoder as Xing, and not FhG. Though EncSpot still reports FhG.

I have to admit, Gambit rocks. I love programs with a sense of humour, and this has one - which is a change among the humourless code we see mainly.

I'd even use the thing, if it supported 'flattening' a directory structure of files, so I didn't have to go to each album subdirectory to see stuff

How would I go about adding a "View with Mr Questionman" option to the context menu of folder in Windows XP, like with Encspot?

Or is this something that Gambit would have to add support for?

The preset guessing comes from the LameTag.exe code. It is based purely on a combination of the values in the Lame tag fields, which do not vary from file to file for a particular preset and lame version. I tested it fairly comprehensively, so I am almost certain that if you have an mp3 file that was encoded with a preset and no other command line options then it will be guessed correctly. If other command line options were used then you will get "<not stored>" because it is not possible to guess from the Lame tag and it would need some other method that analyses the actual audio data, which is is outside the scope of the LameTag.exe functionality.

foobar2000 definitely does remove the Lame tag when you "Fix MP3 header"

is it open source (as lame)?

i'm interested in making Linux branch of it

As getID3() says, it is only the "modified" 3.90.3 that stores the preset used. Even the very latest "standard bundle" 3.90.3 compile from Rarewares does not store this because it is deliberately intended to be identical to 3.90.2 apart from including the -Z switch automatically in --alt-preset standard.


The LameTag.exe preset guessing was only written to cover named presets (insane, extreme, fast extreme, standard, fast standard, medium, fast medium, r3mix, studio, cd, hifi, tape, radio, fm, voice, mw-us, sw and phone). I could look into extending it to cover numbered presets such as --alt-preset 128, but this would only work if they produce distinctive lame tag values when compared to standard abr encodes. I have done a quick check and it looks like this is the case but I will have to do some more exhaustive testing on different bitrates and lame versions. If it looks to be possible then I will update LameTag.exe and Gambit can include the modified classes in Mr QuestionMan.


From 3.94 onwards the whole relationship between the Vx command-line option and the named presets changed. In earlier versions, the alt-presets mapped onto a command line with a number of switches including a Vx value and also some code level tweaks. But from 3.94 onwards the Vx command-line option is itself a tuned preset, so there are ten different vbr presets (V0 to V9). In these versions, preset standard is simply another name for one of these presets: V2. And alt-preset standard is just another name for preset standard.

Okay... thanks for pointing that out. I've downloaded the modified version now. I also see my dyslexia got the best of me once again when I wrote in v3.90.1 instead of v3.90.3. I've edited the error above


That's something I hadn't come across yet. Bare with me here while I wrap my understanding around this one. Are you saying that '--alt-preset standard', 'preset standard', and 'V2' can be run at the command line with the same results? Or are these terms only applicable to output and/or code?

Thank you so much I really like this

Yes

LOL, it blames for having VQF files as well

Great programm, BTW

-Eugene

The link doesn't work...

Wait. What a surprise. Version 0.2 .... How nice

Maybe I should have waited the author to anounce it...

Okay, I've asked Peter and foobar doesn't remove the Lame Tag header, it only removes the encoder info when fixing mp3s. But it seems that the LameTag code doesn't detect the Lame Tag header at all after that. Gotta take a look at that...

I'm certain it does. There's an easy low-tech way to see: create a file with a lame tag and open it in Notepad. You can't read most of it because it's binary, but you can search for text strings. Search for the word LAME and count how many occurrences there are. Run it through foobar2000 fix header, and then reopen it in Notepad and search for LAME again. You will find there is now one less occurrence: this is because the one that identifies the start of the lame tag is no longer there.

Lame tag is identified by either "Xing" or "Info".
The "LAME" string is the encoder name string. As an example, it could also be "GOGO", "FHGF",...

http://gabriel.mp3-tech.org/mp3infotag.html

Yes, I appreciate this. The lametag.exe code looks for "Xing" or "Info" at expected offsets and then looks for the encoder string at the relevant position based on that. It does presume that the encoder string will be "LAME", based on my understanding that at the moment LAME is the only encoder that actually writes a lame tag. Is this incorrect?

The text "Xing" is still found at the expected position in a foobar2000 fixed file, but then in the position where the encoder string and the rest of the lame tag information should be there is just zeros.

I am not sure about this. I would not be suprised if Gogo would be using "GOGO"

I did check the latest version of Gogo I could find at the time when I wrote lametag.exe, and it didn't write a lame tag. But anyway, this only means the code will not read the lame tags correctly from Gogo files if there are any with lame tags. The main point here is that foobar2000 is definitely stripping the lame tag from lame encoded files that had a lame tag before they were "fixed".

I have encountered two bugs in version 0.2:

1) Some files are identified as "alt preset standard -b 128 (modified)" although they're plain APS

2) Sometimes, Questionman repeats files in a folder. When clicking a second time on the folder name, those files disappear.

Regards,

Sven

My guess is that these files were encoded via EAC using the "LAME MP3 Encoder" parameter passing scheme rather than "User Defined Encoder". And that you have 128kBit/s selected in the bitrate box. If this is the case, here is the explanation of why you are getting an incorrect identification. (if not, let me know and I will look into it further):

If EAC has "LAME MP3 Encoder" selected it uses the values in the bitrate box and the quality radio buttons in the command line it passes to lame. For example, with 128kBit/s and "High Quality" selected, and "--alt preset standard" in the additional command line options, it will construct


This is not generally considered to be a big problem because lame gives precedence to the later switches on the command line. So it sees the preset after the other command line options and the preset overrides the -b and -h. The audio data it creates is identical to if simply "--alt-preset standard" had been used. However, unfortunately for some versions of LAME (including 3.90.3), lame still writes the -b value into the Bitrate field of the lame tag. This is fixed in the latest releases of lame such as 3.96, but if you want to avoid it with 3.90.3 select "User Defined Encoder" in EAC instead.

So your audio stream is pure --alt preset standard. But as far as the lame tag is concerned the bitrate is different. In fact the lame tag is identical to if the -b option had been specified at the end "--alt-preset standard -b128". And this command line does produce a different audio stream where the 128 sets the minimum vbr bitrate.

The lametag.exe code that Gambit has used in Mr QuestionMan only reads the lame tag. This is its purpose. It does no analysis of the audio data whatsoever. So as far as it is concerned you have a file that was encoded with a different minimum bitrate to --alt-preset standard. There is no way it can distinguish between "-b 128 --alt-preset standard" and "--alt-preset standard -b 128". This is why I have used rather cagey language in the lametag.exe output for this type of file:


However, in order to fit this neatly into a single cell in a grid, Gambit has truncated all that waffle into simply "(modified)". Which doesn't hedge its bets quite so much.

The only real solution for this is for somebody to write some code that actually analyses the audio data to determine the preset. I have no idea whether this is actually possible and no intention of finding out as I don't care enough. But maybe somebody will. In the meantime, I hope all this makes the situation a little clearer.