[Feature Request] Some log enhancements

[Daniel6372]

1. Peak levels (along with the sector information, called Start/End LSN in cyanrip) are useful for determining differences between different pressings of the same album.
2. Pre-gap length is the pause/silence before a track and it can also help differentiate between different pressings of an album.

How other rippers show this info:

EAC example:

Track 11

     Filename C:\Folder\11 - Track.wav

     Pre-gap length  0:00:20.00

     Peak level 99.8 %
     Extraction speed 4.4 X
     Track quality 100.0 %
     Test CRC 6FAFABD1
     Copy CRC 6FAFABD1
     Accurately ripped (confidence 3)  [C2C18BA2]  (AR v2)
     Copy OK

XLD example:

Track 06
    Filename : /Users/Username/Folder/06 Track.flac
    Pre-gap length : 00:06:57

    Track gain               : -5.11 dB
    Peak                     : 0.996552
    CRC32 hash (test run)    : CDE2B054
    CRC32 hash               : CDE2B054
    CRC32 hash (skip zero)   : AA576BE0
    AccurateRip v1 signature : 6F06FDEE
    AccurateRip v2 signature : 0A3A418F
        ->Accurately ripped (v1+v2, confidence 2+5/7)
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

[cyanreg]

Fixed both by 5285205fda8812a07d3f056a336517c094181e39 Not sure if the new log layout is cleaner or not, or if it could use clearly marked sections.

[Daniel6372]

@cyanreg I think the layout is fine, though it's a lot of information.

As for the peak levels, could they be (also) displayed in the EAC/XLD format for easy comparison/interoperability? I think the format XLD displays the peak in (0.996552) would be most ideal, maybe display it like:

Peak: 0.996552 (-0.1 dBFS)

And for whatever reason -Z stopped working for me after updating from 55cd5dc0f176c088b352aa818c2254ed09ededda. I specify -Z1 and it does 1 rip, then never begins another, just hangs there.

[cyanreg]

You can read the REPLAYGAIN_TRACK_PEAK metadata tag to get the peak. Keep in mind, they're not interoperable with XLD, probably - we compute the true peak, not the sample peak. Use the printed LUFS ( == dBFS for these intents and purposes) value if you have to compare.

[cyanreg]

Fixed repeat ripping mode.

[Daniel6372]

EAC/XLD use the equivalent of sox input.flac -n stats -b 16 and getting the maximum value of the absolute values of Min level/Max level.

That's how whipper does it: https://github.com/whipper-team/whipper/blob/develop/whipper/program/sox.py

Could something like this get added to cyanrip? Maybe ffmpeg can do this somehow. I find these values more precise and convenient than dBFS, LUFS, ReplayGain metadata, etc. and those don't seem comparable anyway.

@cyanreg Btw I did a test rip and the resulting files had no tags at all, only encoder=Lavf60.3.100. So I guess tagging might be broken as well currently. Maybe that's also why all the ReplayGain metadata values were identical in the log for every track:

    REPLAYGAIN_TRACK_GAIN:         -18.00 dB
    R128_TRACK_GAIN:               -3328
    REPLAYGAIN_TRACK_RANGE:        0.00 dB
    REPLAYGAIN_TRACK_PEAK:         1.000000
    REPLAYGAIN_REFERENCE_LOUDNESS: -18.00 LUFS

[cyanreg]

Works fine here. Could you try without -Z1?

[Daniel6372]

That was actually without -Z1, I was using 3b46f352e6e03ae45110882affc57a88c14e5e16. I'll try latest git.

[Daniel6372]

@cyanreg The issue persists. One oddity I've noticed is that even when specifying -G, the output/log says there's embedded cover art. But this has no effect on the actual tags. Without -G, the cover gets embedded, but no other tags are present. Only it and encoder=Lavf60.3.100.

I also used the -R option if it matters.

[cyanreg]

Are you sure? Keep in mind ffprobe/mediainfo won't show you most metadata fields. And most containers don't let you specify arbitrary metadata fields either.

I'm not seeing cover art embedding being indicated at all when there is none. Are you sure your build isn't messed up?

[Daniel6372]

I'm not sure how it would get messed up, and I'm using metaflac --show-all-tags.

[cyanreg]

Right, I missed a line. Should be fixed now.