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: Mr QuestionMan 0.7 released (Read 18164 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Mr QuestionMan 0.7 released

Reply #25 –
Why are there so many differences between MQM and EncSpot guesses about MP3 files?. I´m not saying EncSpot is a golden standard or anything, I just wonder what program is guessing the encoder used with a higher probability of giving the correct answer.

Mr QuestionMan 0.7 released

Reply #26 –
Quote
Why are there so many differences between MQM and EncSpot guesses about MP3 files?. I´m not saying EncSpot is a golden standard or anything, I just wonder what program is guessing the encoder used with a higher probability of giving the correct answer.
[a href="index.php?act=findpost&pid=312376"][{POST_SNAPBACK}][/a]

This has been said many times already: EncSpot mp3 detection is superior for non LAME encoded mp3s.

Mr QuestionMan 0.7 released

Reply #27 –
Quote
This has been said many times already: EncSpot mp3 detection is superior for non LAME encoded mp3s.


Not that it's a time critical process nor your reason but out of curiousity does that translate into
why MQM has a speed advantage?
Just wondering does it have to do with the extra overhead EncSpot has (with the other  data/gui etc..), 
the analysis chart of flow or being the slowest link in the chain is your HD, boil down to qty of frame reads?
(BTW - Whats the min you can get away with?)

Also does MQM accuracy carry over to Gogo encoded files as well?  I can't say for sure they even are
but have seen many instances IIRC where EncSpot reports Gogo (either ver) and MQM mainly shows FhG,
secondly Xing and lastly a few Layer 2 QD.
Though I do have a feeling some of the confused files might be a result of bad splits from a concatenated file.

So is it a toss up or which might be providing the more accurate result?

-- I'm sure it might have been mentioned but I didn't see it in the user's manual
So I feel kind of -LAME- mentioning that I just figured out you can drag & drop the column order!

Mr QuestionMan 0.7 released

Reply #28 –
Problem with dual calculation in MqM 0.7.0.1:

C:\temp\LAME 96    50,93 MB    336    1:12:49    98/45 kbps
http://foobar2000.net/divers/temp/MrQ_dual...eMP3_32KHz.html

Real bitrate is ~98kbps. I don't know how 45 kbps was calculated. I suspect two elements:
- the first one is the 32 KHz sampling rate (but I don't really think that the problem lies here)
- the second is the recursive scanning: the 150 first samples and the 35 last ones are in a separate folder. The first subfolder corresponds to 25 minutes, the second one to approx. the half (13 minutes).


EDIT: can't be reproduced. I've scanned again the folder, and everything is fine 
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

Mr QuestionMan 0.7 released

Reply #29 –
Quote
Quote
Why are there so many differences between MQM and EncSpot guesses about MP3 files?. I´m not saying EncSpot is a golden standard or anything, I just wonder what program is guessing the encoder used with a higher probability of giving the correct answer.
[a href="index.php?act=findpost&pid=312376"][{POST_SNAPBACK}][/a]

This has been said many times already: EncSpot mp3 detection is superior for non LAME encoded mp3s.
[a href="index.php?act=findpost&pid=312390"][{POST_SNAPBACK}][/a]


Thanks for the info Gambit. I thought I had read something about this but I couldn´t remember (maybe it was many months ago...).
I only use EncSpot when analyzing MP3s I get from other people, since 99,5% of my MP3s are encoded with LAME. It´s really nice that MQM correctly detects "-preset standard" encodings as well as other LAME presets.

Mr QuestionMan 0.7 released

Reply #30 –
Gambit,

I noticed this in 0.6.

WMAfile.pas:

Code: [Select]
procedure ReadTagExtended(const Source: TStream; var Tag: TagData);

...

    { Read field name }
    Source.ReadBuffer(DataSize, SizeOf(DataSize));
    FieldName := ReadFieldString(Source, DataSize);
    { Read value data type }
    Source.ReadBuffer(DataType, SizeOf(DataType));
    { Read field value only if string }
    if DataType = 0 then
    begin
      Source.ReadBuffer(DataSize, SizeOf(DataSize));
      FieldValue := ReadFieldString(Source, DataSize);
    end
    else
      Source.Seek(DataSize, soFromCurrent);

...


I think Source.ReadBuffer(DataSize, SizeOf(DataSize)); should be outside the if.  Couldn't say if this is still a problem in 0.7. 

Mr QuestionMan 0.7 released

Reply #31 –
The old WMA code was broken in many places. It was completely rewritten for the new version by jtclipper and me. But thanks for the effort.

Mr QuestionMan 0.7 released

Reply #32 –
Quote
The old WMA code was broken in many places. It was completely rewritten for the new version by jtclipper and me. But thanks for the effort.
[a href="index.php?act=findpost&pid=313199"][{POST_SNAPBACK}][/a]

Not to beat an old Question Man, but yeah there was the use of MaxBitrate instead of ByteRate, and accounting for the header.  Glad to see it was fixed.

Mr QuestionMan 0.7 released

Reply #33 –
Hi !

It looks good, but it doesn't recognise Magix MP3 Maker AAC files.
Since it sounds as the best AAC encoder until now, it should be nice to support this, like foobar does it very well.

Mr QuestionMan 0.7 released

Reply #34 –
Thanks Gambit for this useful tool 
A feature I could appreciate would be a 'refresh' button. When I'm copying around files on my drives, the application does not refresh the directory tree automatically.

Windows XP prof SP2 that is.

edit:
Found it !
Hitting the F3 key does the job.

Mr QuestionMan 0.7 released

Reply #35 –
I just ripped an album and as I suspected that is burned from a lossy source my first step was to open MrQM and have it call auCDtect (v0.8.2).
with MrQM v0.6 I could doubleclick the wav file in the tree view and it would call auCDtect correctly and analyze the file.

now with MrQM v0.71 auCDtect is opened but no scanning takes place, only a general DOS help window about auCDtect is shown.

tried it with other wav files, still the same behavior. I updated MrQM by replacing all files in it's folder, using the provided archive. auCDtect is present in it's folder.

this seems to be a bug in v0.71, as it worked flawlessly before.

[span style='font-size:8pt;line-height:100%']using WinXPSP2[/span]
Nothing but a Heartache - Since I found my Baby ;)

Mr QuestionMan 0.7 released

Reply #36 –
It works fine here. Can you check the bat file in the MrQ directory?

Meh, I need to properly integrate support for auCDtect. This bat solution was just temporary, so I can play around with it.

Mr QuestionMan 0.7 released

Reply #37 –
  now it works fine again. I really don't know what has caused it, I made no changes to my setup since then...
I'm sorry to have bothered you with this.
Nothing but a Heartache - Since I found my Baby ;)
 

Mr QuestionMan 0.7 released

Reply #38 –
guess what comes now... 
right, it doesn't work again.

the DOS output window is exactly the same as if you would run the bat file but not auCDtect (as described in my other post).
is there anything that I can do or are there more infos you need?
Nothing but a Heartache - Since I found my Baby ;)