[ID3 Dev] questions regarding TBPM frame.

[Andy Kernahan]

".....unfortunately, neither one of the apps I use would probably be updated 
to use the new frame."

You have hit the nail on the head there unfortunately. Just changing the 
spec for the TBPM does not mean that the developers of your app will change 
their libs and GUIs to support real numbers.
Also, the developers of newer apps will see that v2.3.0 is by far the most 
implemented version of the id3 standard and will probably continue 
reading/writing tags in that version. The easiest solution to your problem 
is to find an editor that supports real numbers within the TBPM frame and 
stick with it. Sorry to be so pessimistic.

    Andy.

----- Original Message ----- 
From: "darien" <deathboy2000 at earthlink.net>
To: <id3v2 at id3.org>
Sent: Tuesday, November 08, 2005 3:11 PM
Subject: Re: [ID3 Dev] questions regarding TBPM frame.


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



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