|
|
Posted by Billy Joe on 01/18/39 11:25
Don M. wrote:
> "Billy Joe" <see.id.line@invalid.org> wrote in message
> news:J5GdnbExNsl9Q47eRVn-3w@adelphia.com...
>> I used CDex's Edit - "Copy album info to clipboard," to verify that
>> the FREEDB cue sheet is in complete agreement with the CD I was
>> ripping. I also assume that this is the method by which some
>> contributors submit cue sheets to FREEDB?
>>
> ========
>
> CDex has a submit function. Users are not allowed to change times
> AFAIK, only the text portion (names, genre, etc). However, users can
> download tracks from all places on the net and burn an
> official-looking CD, and then submit *that* <yikes>.
> I've seen submissions where titles are "Track01", "Track02", etc, an
> indication that people can submit at will and entries are not
> necessarily screened. I submit corrections on the side (via email)
> when I have the patience. -----------
> It finally dawned on me that I need to check frames after loading a
> cue sheet, so the program does a verification of sorts. I must have
> thought it was going through a fresh check the first time I came upon
> that situation.
>
> Note on 1.2h:
> It assigned number 1 to the last track of an album that has ID3v1 tag
> for the album but not for tracks. It found a "track" after the last,
> as it should have found only 11 tracks in this case (last actual gap
> being smaller than the .75s min. used for checking).
>
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-Analysis.txt
Difficult to explain what I see, but it looks right to me.
First, realize that cuts based on silence are made in "deferred" mode (not
done until another event is detected).
When you look at the analysis data you'll note that:
Silence block: 106913<->106920 for .182 seconds
ends right at the ID3v1 TAG (as expected, and merely reported)
This line:
Silence cut: 95229
is pushing the cut for the silence that occurred earlier.
Now we pick up
ID3v1 at h2A852A8 or 44585640 for 128
Album: The Best of Free
Track: 1
The Track number comes from the tag (I only fabricate Track # when there is
none or it can not be used in a file name).
And note too, that on the next line
ID3v1 cut: 106920
The cut is made for the last block still pending. Since it is an ID3v1 cut,
that tag data is then incorporated.
And yes, if I count all the cuts, there are 12. None of them is oddly
short, tho there are some 3+ minute and some 2+ minute tracks which could,
in fact, have been one tune with a lengthy silence midway thru?
BTW, if this is the case, the way to edit this would be to delete the track
that should have been combined, and add its length to the track which
preceded it. For example, add 2824341, the length of track 10, to the
3354765 length of track 9 - then delete the entire entry for track 10. Only
offsets and lengths are used by the cutter.
If it's not the case, then there are 12 tracks ;-0)
Further BTW, now that I've looked at the cue sheet in the later URLs: There
are 12 tracks. FREEDB starts track count with 0, and the last offset is
always assumed to be EOF. Quirky ;-0)
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-RevisedCuts.txt
> With min set to .18s, it finds the 12th track, reports 12 tracks, but
> assigns #1 to track
> 12.
>
>
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-Analysis_018s.txt
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-RevisedCuts_018s.txt
>
> With cue sheet, min silence set at .18 ( for detection of the last
> gap) the program issues one unpredictable processing warning, lists
> 14 tracks, but [Revise cuts] yields correct cuts:
>
>
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-Cue1_018min_silence.txt
Yep, picked up the brief opening silence in track 1. The "unpredictable"
error will be fixed by making sure that the cue-sheet table bounds are not
exceeded in these cases. I'm going to also issue an alert that there is
something wrong, when we get more cuts than predicted.
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-Cue1-ReviseCuts.txt
>
I believe the way to set up for this cut is to turn off the "Silence"
checkbox.
This will allow the cuts to be placed in the cue-sheet predicted area,
rather than be overruled by silence. You should then see each "prediction
frame" reported as mid-silence.
That "Prediction frame: 18452" Looks like a bug? I'll see if I can figure
it out from what's shown. Clearly the cue-sheet predictions had an entry at
18439, just a few lines earlier and it is recorded in the "Silence cut"
following this bug.
Looks as if the cue-sheet entry table was improperly increment after 18452.
> The warning must have been caused by the .18 limit because it doesn't
> happen with min set back to .75. Results are a little off, there is
> negative frame count .for one of the tracks (#3), but the one
> eliminated in the revised cut list was the last track, #12. Check
> frame with cue sheet and .75 min silence:
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-Cue2_075min_silence.txt
> Revised cuts:
> http://home.comcast.net/~FAQList/ammw/2005-08-28-v12h-Free-Cue2-ReviseCuts.txt
>
> For reference:
> Freedb cue sheet:
> http://home.comcast.net/~FAQList/ammw/2005-08-28-FreedbXmcd.txt
> The FhG rip:
> http://home.comcast.net/~FAQList/ammw/2005-08-28-Free-FhG-details.txt
> MP3MergerOutput(Free-Best of).mp3: album made by joining the FhG
> tracks in MP3Merger, which removed all individual tags and added a
> ID3v1 tag to the album.
>
>
Great help again, Don!!!
Will have some new code later this evening.
BJ
[Back to original message]
|