[ID3 Dev] questions regarding TBPM frame.

[Andy Kernahan]

Darien,

    the ID3v2.X.0 standard clearly states that the TBPM frame contains a 
string representation of an integer, so the values 132.68 and 95.35 are 
invalid.
I would not personally recommend changing the current specification of the 
TBPM frame to allow for high precision bpm values but instead I would 
suggest
you submit a proposal for a new frame (PBPM?). This would allow TBPM aware 
applications to prefer the high precision frame over the standard TBPM frame
whilst also ensuring that existing non-aware applications remain intact.

    Andy.

----- Original Message ----- 
From: "darien" <deathboy2000 at earthlink.net>
To: <id3v2 at id3.org>
Sent: Monday, October 31, 2005 2:07 PM
Subject: Re: [ID3 Dev] questions regarding TBPM frame.


>
> hey there Pyt ...
>
> thanks for replying.
>
>>Strictly speaking, TBPM is a text frame, so it is very possible for it to 
>>be set to just about anything textual if a program would allow it. 
>>However, the v2.4 spec is pretty clear that it is an integer and that it 
>>is beats per minute, so you cannot set it to 123.45, and even though you 
>>could set it to 12345, but that would probably meaningless from a musical 
>>standpoint...
>>
>>I guess your programmer must have decided that more than 999 beats per 
>>minute is nonsense, which can be understood but is indeed going a bit 
>>further than the spec intends.
>>
>>Not sure this helps...
>
> it sort of does ... it's brought a couple of things to light, and i have a 
> question...
>
> how does one go about getting the spec for the TBPM frame changed to allow 
> for a decimal place and 'non-whole' bpm measurements (ie 132.68, 95.35, 
> etc) as allowable and legitimate data for the spec?
>
> i feel that it's not right the way it is, i can think of quite a few 
> arguments for why the 'standard' should be changed to allow a decimal 
> place if desired or needed, and i'd like to push to have it changed. it 
> would make my life a bit easier in a few different ways, and i reckon it 
> would probably help other people out there as well.
>
> bpm measurement is *never* a solid, honest-to-goodness integer. well, not 
> practically, anyway. it's usually measured in averages, because there are 
> no recordings out there that are perfectly on-beat from start to finish 
> ... there are many obvious reasons why... neither midi clocks nor human 
> drummers are ever 100% on the money with regard to keeping time, hence 
> having bpm measurements of 132.68, 95.35, etc. while midi clocks come 
> close, there's always a little bit of slide with regard to the accuracy of 
> its' generation. human drummers are never 100% -- every human drummer is 
> always off the mark by some percentage (usually depending on how drunk 
> they are). the only thing that is pretty much right-on is smpte, and a 
> large percentage of professional musicians don't use smpte for clock 
> generation (though there are a few out there that do, especially if 
> they're working in hollywood on film or television projects).
>
> most software applications that measure bpm properly do not end up with a 
> bpm measurement that is a whole integer either (here's one i know of 
> that's free and writes the value into the id3v2.x tag : 
> http://www.mixmeister.com/download_freestuff.html ) ...
>
> i'm a dance music dj and i play a lot of electronically-based music. i 
> play house, prog house, hip hop, breaks, and i play some mobile dj gigs 
> too if the money's right. years ago, i used to exclusively dj with vinyl 
> records and cd's, but now i use traktor dj studio to dj with. traktor dj 
> studio has the ability to be able to control/manipulate playback of mp3's 
> using a special hardware audio interface and vinyl records with a 
> recording of timecode cut onto them. the timecode records tell the 
> computer what pitch the record is playing back at, where the needle is on 
> the record and so forth. the records and hardware are essentially a 
> control interface, and a brilliant one at that.
>
> about 80% of the mp3's i generate to dj with are from recordings of vinyl 
> records, because that's the medium of choice for dj'ing electronic 
> music -- a lot of prime stuff gets released on vinyl that never sees a 
> digital release, even in this digital world of ours. vinyl, as a rule, is 
> an imperfect medium, which opens up a pretty huge can o' worms in itself 
> with regard to bpm and speed in general. here are some examples of things 
> that cause timing issues with vinyl records:
>
> o - vinyl records are never perfectly flat. every record pressed (even a 
> 180 gram audiophile grade record) has a certain degree of warp to it. they 
> can be really close to flat, but never perfectly flat
> o - the stamper plates used to press records are made of nickel, and a 
> high amount of pressure is placed on them for every record pressed -- it 
> takes 120 tons of pressure to press a vinyl record. as a result, every 
> pressing degrades the stampers slightly. stampers are only good for 1000 
> pressings. after that, the stampers will have degraded enough to create a 
> noticably imperfect product and a new set of stampers must be used.
> o - consistency of the vinyl material differs slightly from batch to batch
>
> couple these factors with a midi clock that doesn't generate time 
> perfectly and you've got a recording that isn't going to be anywhere near 
> perfect, timing and bpm measurement-wise.
>
> this is just one example. another that i could explore is disco or funk 
> tracks from the 70's... parliament, the bee gee's, gloria gaynor, cheryl 
> lynn, donna summer, etc. all of that stuff was recorded onto analog tape, 
> and human drummers were employed. analog tape stretches and shrinks with 
> temperature and general use. tape machines of the day weren't digitally 
> regulated, and no analog motor is perfect. pair those imperfections with a 
> human drummer and loads of disco or funk swing, and you've got a recording 
> that isn't anywhere near a whole integer bpm-wise.
>
> so yeah ... some good arguments there. ;)
>
> any advice on how to go about getting the spec changed for the TBPM field 
> would be greatly appreciated.
>
> cheers.
>
> --darien!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org