Older blog entries for edp (starting at number 6)

7 Apr 2004 (updated 7 Apr 2004 at 03:05 UTC) »

ok, i made some progress...

cdparanoia uses "LBA" mode in the ioctl to read cd Table Of Contents.

other code uses "MSF" (minutes, seconds, frames) mode instead.

using both modes shows the familiar 150 frame difference (M:S.F -> total vs LBA):

  1.  0:02.33 ->    183 vs     33; delta = -150  [format: 2, datamode: 0]
  2.  2:39.23 ->  11948 vs  11798; delta = -150  [format: 2, datamode: 0]
  3.  3:56.35 ->  17735 vs  17585; delta = -150  [format: 2, datamode: 0]
  4.  6:13.68 ->  28043 vs  27893; delta = -150  [format: 2, datamode: 0]
  5.  8:57.53 ->  40328 vs  40178; delta = -150  [format: 2, datamode: 0]
  6. 10:17.13 ->  46288 vs  46138; delta = -150  [format: 2, datamode: 0]
  7. 11:22.55 ->  51205 vs  51055; delta = -150  [format: 2, datamode: 0]
  8. 13:05.10 ->  58885 vs  58735; delta = -150  [format: 2, datamode: 0]
  9. 14:17.03 ->  64278 vs  64128; delta = -150  [format: 2, datamode: 0]
 10. 15:29.38 ->  69713 vs  69563; delta = -150  [format: 2, datamode: 0]
 11. 17:52.58 ->  80458 vs  80308; delta = -150  [format: 2, datamode: 0]
 12. 18:58.50 ->  85400 vs  85250; delta = -150  [format: 2, datamode: 0]
 13. 20:22.58 ->  91708 vs  91558; delta = -150  [format: 2, datamode: 0]
 14. 22:10.05 ->  99755 vs  99605; delta = -150  [format: 2, datamode: 0]
 15. 25:07.65 -> 113090 vs 112940; delta = -150  [format: 2, datamode: 0]
 16. 26:27.55 -> 119080 vs 118930; delta = -150  [format: 2, datamode: 0]
 17. 28:35.25 -> 128650 vs 128500; delta = -150  [format: 2, datamode: 0]
 18. 31:46.08 -> 142958 vs 142808; delta = -150  [format: 2, datamode: 0]
 19. 33:02.48 -> 148698 vs 148548; delta = -150  [format: 2, datamode: 0]
 20. 33:58.05 -> 152855 vs 152705; delta = -150  [format: 2, datamode: 0]
 21. 34:47.68 -> 156593 vs 156443; delta = -150  [format: 2, datamode: 0]
 22. 36:02.48 -> 162198 vs 162048; delta = -150  [format: 2, datamode: 0]
 23. 39:00.55 -> 175555 vs 175405; delta = -150  [format: 2, datamode: 0]
 24. 39:54.43 -> 179593 vs 179443; delta = -150  [format: 2, datamode: 0]
 25. 41:09.45 -> 185220 vs 185070; delta = -150  [format: 2, datamode: 0]
 26. 42:54.33 -> 193083 vs 192933; delta = -150  [format: 2, datamode: 0]
 27. 50:15.10 -> 226135 vs 225985; delta = -150  [format: 2, datamode: 0]
 28. 51:34.03 -> 232053 vs 231903; delta = -150  [format: 2, datamode: 0]
 29. 52:56.63 -> 238263 vs 238113; delta = -150  [format: 2, datamode: 0]
 30. 54:19.70 -> 244495 vs 244345; delta = -150  [format: 2, datamode: 0]
 31. 56:55.55 -> 256180 vs 256030; delta = -150  [format: 2, datamode: 0]
 32. 59:05.15 -> 265890 vs 265740; delta = -150  [format: 2, datamode: 0]
170. 61:39.73 -> 277498 vs 4794173; delta = 4516675  [format: 2, datamode: 0]

uh, except for the lead-out track; i dont know what's up with that.

been learning about audio CD format...

Andy McFadden's CDR FAQ is awesome.

(His page about file formats is also highly recommended.)

i still don't know why cdparanoia prints (typically) 00:00 instead of 00:02 which is returned by the "read TOC" cdrom ioctl for the first track. is it just blindly subtracting 2 seconds or what? must read the source... anyway despite the FAQ i don't understand the exact nature of this 2-second gap.

freedb really is a mess (accurate criticism by jwz). i wonder if there is hope. i'd like to help...

gilbou: thx for the hashing suggestion.

regarding Jazz, how about making its homepage this wikipedia entry instead of the Bluenote label? ;)

i was thinking of submitting some jazz information to coversproject.com...

i have a fair number of jazz cds, which include many "covers" of standards, naturally, and i'd like to have an index of them by song name, so i could easily find all recordings in my library of any song.

i've currently done that only for certain things, like John Zorn's Masada, Art Tatum, and JS Bach (by BWV number).

27 Mar 2004 (updated 27 Mar 2004 at 19:03 UTC) »

music archive TODO:

  1. capture CD audio.

    [CDDA]Paranoia works great.

  2. uniquely identify CD.

    AFAIK there is no way to fully automate this in general.

    existing schemes use number, length, type of tracks. obviously it is easy to "fool" such a system simply by releasing a CD with the same number, length and type of tracks as another CD. so there must be a way to resolve collisions.

    i wonder about matching the extracted audio data exactly. my vague understanding is that there is ambiguity in where the "real" audio data starts (even if the real audio data can be extracted bit-for-bit perfectly). i wonder whether one could get repeatable results by stripping leading frames which were totally silent?

    (also note of course that there exists music which does not come from commericial audio CD. so there must be other ways of identifying music.)

  3. manage other "metadata".

    eg label, release, artist, track info, cover art, liner notes.

    this is by far the most difficult part.

    want to submit/sync/check (some subset of) this stuff to/with/against free music information services like freedb and MusicBrainz.

i've been using GNU software since 198x. first Emacs, then GCC et al.

today i joined the FSF as an Associate Member. finally!

submitted BCEL changes today. one minor doc fix was applied immediately. we'll see what happens with the other stuff.

(haven't yet brought up ideas on enhanced support for dealing with targeters, exception-handler regions, etc. i'll get to that...)

so far, my contributions to free software have been minimal:

  • i've donated money to the Perl Foundation;
  • i've paid money to RedHat;
  • i've reported bugs in various things;
  • i've helped debug emacs (many years ago);
  • i've submitted patches for emacs (many years ago).

things i haven't done which i should:

  • donate money to the FSF;
  • submit StackMap enhancement to BCEL;
  • suggest certain improvements to BCEL...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!