[ID3 Dev] questions regarding TBPM frame.

[darien]

hey there andy.

thanks for taking the time to drop a reply to this thread...

>    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.

i honestly think it would be better to change the TBPM frame to allow both.

the reason why i think that way is that most of the apps i've seen 
that handle BPM measurement and store it in the TBPM frame all store 
a non-whole number. i've only seen a couple of apps that adhere to 
the standard, and the rest ignore it and store a non-whole 
measurement (ie 13278) in that frame. one of the oldest 'pro' apps 
that i know of, PCDJ Red, stores that information in the TBPM frame. 
i haven't seen a version of that app in quite a while, but the last 
version i saw put a value like '13278' in there.

because there are apps that i use to do bpm measurement that probably 
won't ever be updated (mixmeister bpm analyzer, flatfeetpete's 
recordboxing app : 
http://sourceforge.net/project/showfiles.php?group_id=70378 ) to 
adhere to a standard, i think it would be better to change the 
standard of that frame to allow both. since apps already stick 
non-whole numbers in there, i reckon that devices/apps that look at 
that frame already round off non-whole numbers that they see already 
if that is necessary. it would be nice though to have newer apps that 
adhere to the standard not round off the number if they see a 
non-whole number in the frame. i have several thousand files that 
have all had their bpm measurements done, and i don't want to have 
them all rounded off, as it has taken hours of cpu time to analyze 
them. i am not a programmer, and i can't write an application that 
would convert the values to a new frame, and don't have the money to 
hire a programmer to do that either ... and unfortunately, neither 
one of the apps i use would probably be updated to use the new frame.

so again, i ask ... how does one get the standard changed to allow 
both types of entries?

cheers for any advice.

--darien!






>----- 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



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