Parameters
Many structures and quantities in Polyscope have optional values which can be set to control their appearance or behavior, such as the radius of points in a point cloud or the color of a mesh. These values can generally be manually adjusted in the GUI, or set programmatically in code.
This page documents special features in Polyscope which provide extra functionality while setting these parameters.
Persistent values
In Polyscope, if you manually set the color of points in a point cloud (for instance), then register a new point cloud with the same name overwriting the original, the new point cloud will inherit the old point cloud’s color. This functionality, and other similar behavior, is implemented via persistent values.
Persistent values are lightweight wrappers around a variable which on-construction look up the variable in a global cache, and if a cache entry exists take the cached value instead. Any time the variable is written to, its value is recorded in the global cache. Generally, the cache key includes the name of a structure (and quantity if applicable), so a cached variable will only be picked up when names match.
Generally, the user should not manually interact with persistent values ever, all you need to know is that some variables may “magically” remember their old values by pulling them from a cache.
PointCloud* psCloud = polyscope::getPointCloud("my cloud");
psCloud->setPointColor(glm::vec3(0.5, 0.5, 0.5));
// the persistent value is recorded in the cache
// ... later ...
PointCloud* newCloud = polyscope::registerPointCloud("my cloud", new_points);
// newCloud will automatically pick up the pointColor we set above,
// since this point cloud has the same name
for implementors
If writing custom Polyscope library code (e.g. your own custom structures and quantities), here’s what you need to know to use persistent values.
The class PersistentValue<T>
is templated on the underlying scalar type, like PersistentValue<double>
. Only a predefined set of types can be used as template arguments because the corresponding global cache must be allocated. See persistent_value.h
for a listing, which currently includes bool
, float
, double
, ScaledValue<float>
, ScaledValue<double>
, glm::vec3
, and std::string
.
Construct a persistent value like
PersistentValue<float> myVar("unique_name", 0.5)
0.5
(and add it to the cache). Remember to use a globally unique name for the for the name argument; in structures you can use a concatenation of the type name, structure name, and (if applicable) quantity name.
To access a persistent value, call myVar.get()
, which returns a reference to the underlying value.
In some occasions, in particular when using ImGui, you may need to write to a value directly via the pointer from &myVar.get()
. This is problematic, because the variable does not know it has been written to and thus needs to update the cache. The function myVar.manuallyUpdated()
can be called to notify the persistent value that it needs to update the cache. The paradigm for using a persistent value with ImGui then looks like
if (ImGui::SliderFloat("some text", &myVar.get())) {
myVar.manuallyChanged();
}
Scaled values
Specifying appearance (such as the radius of points in a point cloud) in global length units can be inconvenient; its generally much easier to set values relatively, which respect to some reasonable length scale.
The ScaledValue
type tracks such represents such values, if we set ScaledValue s = 7.
, then s.asAbsolute()
will return 7. * state::lengthScale
when used.
Most length-valued parameters in Polyscope use this mechanism, and thus are relative by default.
using namespace polyscope;
PointCloud* psCloud = polyscope::getPointCloud("my cloud");
// radius will be 0.05 * lengthScale when used
psCloud->pointRadius = ScaledValue<double>::relative(0.05);
psCloud->pointRadius = relativeValue(0.05); // shorthand, same as previous
psCloud->pointRadius = 0.05; // shorthand, same as previous
However, sometimes you might want to actually use an absolute value for a parameter, for instance to get exactly the same appearance between runs of a program on different data. To support that, scaled values can optionally be set as absolute values, which will not be scaled before use.
// radius will be 1.6 when used
psCloud->pointRadius = ScaledValue<double>::absolute(1.6)
psCloud->pointRadius = absoluteValue(1.6); // shorthand, same as previous
Note that scaled values can be (and often are) used as persistent values, as described above; the two concepts are complementary.
for implementors
If writing custom Polyscope library code (e.g. your own custom structures and quantities), here’s what you need to know to use scaled values.
The class ScaledValue<T>
is templated on the scalar type, which basically just needs to support scalar multiplicaiton.
The examples above show how to construct scaled values as relative or absolute.
If you want to get the value represented by the ScaledValue
as an absolute quantity, use ScaledValue<T>::asAbsolute()
, which scales by state::lengthScale
if the value is relative.
Use ScaledValue<T>::getValuePtr
to get a pointer to the underlying T
, for instance if using ImGui. A basic ImGui pattern to manipulate the variable looks like:
ImGui::SliderFloat("value ", value.getValuePtr());
If the value is a persistent scaled value, like PersistentValue<ScaledValue<float>>
, it can be used like:
// example persistent scaled value
PersistentValue<ScaledValue<float>>> myVal("unique name", relativeValue(0.03));
// access
float myValInWorldCoords = myVal.get().asAbsolute();
// use with ImGUI
if (ImGui::SliderFloat("my val", myVal.get().getValuePtr())) {
myVal.manuallyChanged();
}


MADDIE is a designer
with a broad skill set of
visual communication
STUDYFORCE
text-heavy web design
Personal portfolio
web design
iOS Camera Filter
Mobile App Design
TNS Printer Locator
Mobile App Design
Javascript
Pattern animation
Birthday Visualization
Pattern design
Weather API
Visualization
Visiting designers
Interactive Poster
Macbeth
Visual experience
Jquery
Exercise


FROM: WILLIAM ZUNGU JOHANNESBURG REPUBLIC OF SOUTH AFRICA E-MAIL<EMAIL_ADDRESS>Attention: President C.E.O URGENT FINANCIAL ASSISTANCE I know you will be surprised to hear from me since you don�t know me personally. I am WILLIAM ZUNGU , the son of Dr. ZUNGU who was recently murdered in the land dispute in Zimbabwe. I got your contact through your country�s Information Exchange in my search for a reliable and reputable person to handle a very confidential transaction, which involves a transfer of fund into a foreign account and I decided to write to you. The war veterans of the ruling Government of President Robert Mugabe for their alleged support murdered my late father among the few black Zimbabwean rich farmers in cold blood for the Movement of Democratic Change (MDC), which is against Mugabe�s rule. The land problem arose when Mugabe introduced a New Land Act that wholly affected the rich white farmers and some blacks vehemently condemned the � modus operadi� adopted by the government. This resulted to rampart killings and mob action by the war veterans and thugs. More than 78 people have so far been killed. Heads of Government from the West, especially Britain and United States of America have voiced their condemnation of Mugabe�s Land Act. Subsequently, South Africa Development Community (SADC) has continuously supported Mugabe. It is against this background that my family and I who are currently in South Africa have decided to transfer this money out of Africa as we no longer feel safe anymore and want to transfer this money to a foreign country where we can establish ourselves. Just before my father�s death, he took me to Johannesburg, South Africa to deposit the sum of US$30.0000.00 (THIRTY MILION UNITED STATE DOLLARS) with a security and finance company, as he foresaw the looming danger in Zimbabwe. This money was deposited in a box as valuables to avoid much demurrage from the finance company. This amount was embarking for the purchase of new farms machinery and chemicals, as well as the establishment of some new farms in Lesotho and Swaziland. As the eldest son of my father, I am saddled with the responsibility of seeking for genuine foreign account where this money could be transferred into without knowledge of my government who are tactically freezing our family�s wealth and the South African government seems to be playing along. I am faced with the dilemma of investing the money here since both countries have almost the same history. More so, the South African Foreign Exchange does not allow such investments as I am seeking for asylum. As a businessperson whom I have to entrust my future and that of my family, I must let you know that there is no risk and the nature of your business does not necessarily matter. Therefore, should you be able and willing to help me and my family, we are willing to offer you 30% of the total sum for your assistance, 10% will be set aside for expenses we may incur while the rest 60% will be for my family. It is our wish to invest our money on commercial property based on your advice and I will also receive assurance that you would not sit on this money when transferred into your account. If this proposal is acceptable by you, please confirm your interest via my EMAIL.please i want you to include your private telephone number for easy communication. Best regards, William _________________________________________________________________ Have a video conversation in real time - Get MSN Messenger - FREE download. http://messenger.msn.co.za?DI=1054&XAPID=2532


GLorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.
GLorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.


| 028:085 Khan | : |
Verily, He Who has given you (O Muhammad SAW) the Qur'an (i.e. ordered you to act on its laws and to preach it to others) will surely bring you back to the Ma'ad (place of return, either to Makkah or to Paradise after your death, etc.). Say (O Muhammad SAW): "My Lord is Aware of him who brings guidance, and he who is in manifest error." |
| 028:085 Maulana | : |
He who has made the Qur'an binding on thee will surely bring thee back to the Place of Return. Say: My Lord knows best him who has brought the guidance and him who is in manifest error. |
| 028:085 Pickthal | : |
Lo! He Who hath given thee the Qur'an for a law will surely bring thee home again. Say: My Lord is Best Aware of him who bringeth guidance and him who is in error manifest. |
| 028:085 Rashad | : |
Surely, the One who decreed the Quran for you will summon you to a predetermined appointment.  |
| 028:085 Sarwar | : |
(Muhammad), God, Who has commanded you to follow the guidance of the Quran, will certainly return you victoriously to your place of birth. Say, "My Lord knows best who has brought guidance and who is in plain error." |
| 028:085 Shakir | : |
Most surely He Who has made the Quran binding on you will bring you back to the destination. Say: My Lord knows best him who has brought the guidance and him who is in manifest error. |
| 028:085 Sherali | : |
HE who has made the teaching of the Qur'an binding on thee will most surely bring thee back to thy ordained place of return. Say, 'My Lord knows best him who has brought the guidance, and him who is in manifest error.' |
| 028:085 Yusufali | : |
Verily He Who ordained the Qur'an for thee, will bring thee back to the Place of Return. Say: "My Lord knows best who it is that brings true guidance, and who is in manifest error." |
Concepts/Themes Covered: أركان الإسلام > التوحيد > توحيد الله تعالي > ربوبيته جلّ وعلا Pillars of Islam> Islamic> Oneness of Allah> His Divinity, the Great and Almighty أركان الإسلام > التوحيد > توحيد الله تعالي > صفات الله تعالى > أعلم Pillars of Islam> Islamic> Oneness of Allah> His Glory's Characteristics> The One who Knows Better أركان الإسلام > التوحيد > توحيد الله تعالي > علمه جلّ شأنه Pillars of Islam> Islamic> Oneness of Allah> His Glory's Knowledge أركان الإسلام > (محمد (صلى الله عليه وسلم > تأييد رسالته Pillars of Islam> The Blessed Muhammad(PBUH)> Supporting his Message أركان الإسلام > (محمد (صلى الله عليه وسلم > تسليته وتثبيته Pillars of Islam> The Blessed Muhammad(PBUH)> Cheering and Consolidating Him الإيمان > اليوم الآخر > أسماؤه > الميعاد Faith> The Hereafter> The Hereafter Names> The Appointed Day الإيمان > اليوم الآخر > الحشر Faith> The Hereafter> The Day of Resurrection القرآن الكريم > وصفه ووجوب الإيمان به The Holy Quran> The Description and the Necessity to Believe it
This tool uses eight English parallel translations for the Holy Quran imported from Mr. Clay Smith. You can also visit Qurany Concepts for browsing the Quran themes or topics. If you want to search the Holy Quran for keywords, please visit Qurany Keywords.


Let's Talk
Connecting World together !
Create Room
Join
Its free, secure and exciting, Try Now
Host Video
meeting
in one Click


{% extends 'layouts/base.html' %} {% import 'macros/form.html' as f with context %} {% block title %}Contact us with your feedback or issues{% endblock %} {% block meta_description %}Contact our customer service department with any questions or concerns.{% endblock %} {% block body %}


We are, more than anything else, lovers of exquisite tea. We love everything about tea – its rich heritage, many complexities and sheer variety.We imagine Chai Safari as a delicious journey to experience all of this and more.
And it’s
a journey we would love to share with you ❤ !


Welcome to PIZZA HOUSE
HOME
MENU
ABOUT US
CONTACT US
You are our valuable customer!!!
Your
FEEDBACK
will be valuable to us


Twilight Sparkle Forum
Sign In
Sign Up
Sign up
Username
Password
Password confirmation
Password must:
must contain at least 8 symbols;
must contain lower case letters (a - z);
must contain upper case letters (A - Z);
must contain numbers (0 - 9);
Email


----------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------
1
Human Resources Policies
Probation Policy
FUNCTION: HUMAN RESOURCE MANAGEMENT
POLICY: PROBATION POLICY
PREPARED BY: GAGANDEEP SINGH
APPROVED BY: BHARAT KAPOOR
DATE: 1
st
December, 2015
VERSION NO: HR/PP/ 01- A
Policy Number
HR/ PP/ 01
Policy
Distribution
All Employees
Confidentiality
Confidential to DIPI employees
Effective Date
December 2015
Objective
To ensure proper assessment of
an employee’s fitment for a given role in
the company;
To ensure a defined probation period for employees of each Grade;
To ensure defined guidelines to be fo
llowed for employee’s confirmation
or probation extension.
Applicability
This policy is applicable to all the employees of the Company.
This policy will not apply to contractual personnel, consultants and personnel
who are not on the rolls of the Company
.
Policy Content
Probation means an initial review period during which an employee is
evaluated on a range of parameters with the objective of assessing his/ her
suitability for a given role.
Probation Duration:
6 months
Probation Extension:
1-3 Months
Probation Review Process
a)
HR Department shall initiate the process of probation completion 15 days
before the date of completion and intimate the
employee’s
Supervisor
and respective HOD for filling the Probation Review Form.
b)
Supervisor and HOD reviews the performance of the employee and
accordingly fills the Probation Review Form at least 10 days before the
completion of the period of probation.
c)
Supervisor and HOD, will decide either of the followings:
To confirm the employee, if the performance is satisfactory
To allow one time extension of 1-3 months, if the performance is
not adequate
If the performance is not adequate even post extension, the
employee will be terminated
d)
The recommendation of the Supervisor to confirm / extend the period of


scollector
Bosun's metric agent and replacement for OpenTSDB's TCollector
Download Binaries
{% if site.github != null %}
{% assign releases = site.github.releases | where:"draft",false %}
{% assign release = releases[0] %}
{% assign relname = release.tag_name %}
Version {{relname}} ({{ release.created_at | date_to_string }})
{% else %}
View latest release on Github
{% endif %}
View the Project on GitHub
Overview
scollector is a replacement for OpenTSDB's TCollector and can be used to send metrics to a Bosun server.
Benefits of scollector over TCollector:
- scollector uses the HTTP based API, not the older Telnet based API
- scollector is written in Go and is more resource efficient
- scollector integrates with Bosun's metadata (Units, Gauge/Counter, Description) and allows external collectors to also use metadata
OpenTSDB 1.0 uses the
tcollector
data collection framework.
This project aims to make scollector the
preferred collector for OpenTSDB 2.0.
Documentation
configuration
process monitoring
external collectors
See also: Stack Overflow Scollector documentation topics
Installation from Source
$ go get bosun.org/cmd/scollector
Collectors
scollector has the following built-in collectors. See documentation for configuration settings.
Linux
- conntrack
- cpu
- disk
- loadavg
- memory
- network (ifstat)
- processes
- uptime
- Yum
Windows
- .NET proccess memory and AppDomains
- Active Directory
- cpu
- disk
- DSC
- IIS
- memory
- network
- processes
- services
- sntp
- SQL Server (MSSQL)
Mac
Other
- Apache mod_info
- Cassandra
- Chef
- CloudFlare Railgun
- Dell hardware (omreport)
- Elasticsearch
- Exim
- HAProxy
- HBase
- httpUnit
- Keepalived
- Memcached
- NetBackup
- ntp/sntp
- OpenTSDB
- Oracle Database
- Puppet
- RabbitMQ
- Redis
- Riak
- Varnish
Remote Services
- Amazon Web Services (EC2, ELB)
- icmp (ping)
- snmp (Cisco, MIBs/OIDs)
- VMware vSphere


QR Box - Prefrences
Bit.ly Username:
Bit.ly API Key:
To enable bit.ly shortened links input both a valid bit.ly username and API key.
Visit
http://bit.ly/a/your_api_key
to register for a bit.ly account and API key.


Ooni praises husband for standing behind Prophetess Olubori
by https://www.facebook.com/alao.h.joshuaBy Olushola Victor
Despite being a traditional ruler, Ooni of Ife, Oba Adeyeye Ogunwusi, doesn’t joke with things that concern God. For instance, visiting churches is a regular routine for him.
Recently, the Ooni paid a visit to Havilah Mountain of Fire for the church’s 20th anniversary. The seven-day event ended with praise and worship session to celebrate God and the Ooni witnessed it.
He commended Prophet Israel Olubori for being a pillar behind his wife, the founder of the church, saying his solid support and respect for the prophetess had made her flourish.
He said: “We thank God for the family of Olubori and we thank God for making them the leaders of this church. I thank the husband because he supports and respects the prophetess. I am happy I witnessed today’s celebration. I let go of many things to be here today because I didn’t know what to tell the prophetess. If anyone says there is no God, it is a big lie. He is the King who crowns all kings. If you are making the prophetess happy, good things will continue to happen to you.”
The Ooni also presented a gift, a symbolic drawing, to the couple, describing it as priceless.
A representative of Oba Saheed Ademola Elegushi, CSP Dolapo Badmus, Oba Munirudeen Lawal of Ede, Yinka Ayefele and a host of other top personalities graced the event.


Video Example
Play Video (takes a few seconds to create)
Captcha Example
EaselJS (client)
EaselJS (server)
Graphics Test
SpritesheetBuilder Test


E-Filling
Personal Detail
Name :
Date-Of-Birth:
Address :
State :
District :
Pincode :
Gender :
Male
Female
Other
Aadhar No:
Phone :
E-Mail :
Case Detail
Case Subject:
Case Full Description


There are many collection interfaces in .NET world.
Do you know their differences?
What would you like to do?
Please let us know a bit about you...
Please answer a few of questions below:
{{ q.text }}
Based on your answers, the best interface for you is...
{{ interface.typeName }}
{{ interface.namespace }}
Learn more about the interface


About
After rOpenSci, I worked with OurResearch as the product owner/developer on Unsub.
From 2012-2014 I was a postdoc in the Biology Department at Simon Fraser University in Vancouver, Canada.
Before the postdoc at Simon Fraser University I did my master’s degree and Ph.D. training at Rice University in Houston, TX. There I studied a range of topics, including: ant-plant interactions, pollination, population and community ecology, species interaction networks, and evolutionary ecology.</p>
In addition to doing science, I was involved in a number of projects. I was the blog editor for the Journal of Ecology until December 2013. I was on the Community Education and Engagement Working Group at DataONE, and helped organize iEvoBio 2014!


Created by Stefan Christen and Patrick Bucher
Stefan Christen
Stefan Christen is a carpenter and studies computer science at HSLU in the seventh term. Besides his studies, he works as a simple project manager in an IT company which is located in the wood industry. You can find further information on LinkedIn.
Patrick Bucher
Patrick Bucher studies computer science at HSLU in the seventh term, and works as a software and DevOps engineer. He likes simple software (Unix, plain text, the Go programing language) and used to have other interests before studying at HSLU. Most of his code can be found on GitHub.


{if $currentAlbum}> <{/if}>
Toggle navigation
Parse Albums
Dashboard
<{$smarty.session.username}>
Profile
Logout
New Album
<{foreach from=$albums item=album}>
getObjectId()}> class="active" <{/if}>>
<{$album->name}>
<{/foreach}>
<{if $currentAlbum}>
Your browser doesn't have Flash, Silverlight or HTML5 support.
<{else}> Please select an album to view the pictures. <{/if}> <{$content}>


description
Line charts are most commonly used to show
temporal changes
or trends in quantitative data. As the data points are connected, it is expected that consecutive points are
related
to each other.


Whip Down
From half guard lockdown, if opponent has you flat on your back, get the arms in tight to lift op while bringing legs up and to your RIGHT,
you should now have some room to move onto right side, get the left underhook and right to the inner thigh (electric underhooks).


|
|
|
Troop 820, B.S.A. Occoneechee Council, Chapel Hill, NC
|
|
HOME
|
Troop 820 Photos
|
Troop 820 Eagle Scouts
|
Aims & Methods of Scouting
|
|
|
Welcome
to the public homepage of Troop 820. Troop 820 is a Troop for boys. We are sponsored by St. Thomas More Catholic Church. We meet Thursday evenings from 7:30-9:00 p.m.
at St. Thomas More School,
920 Carmichael Street in Chapel Hill. The last Thursday includes Board of Reviews.
Our programming includes monthly campouts, Summer Camp, service projects, merit badge classes, and lots of fun. We are currently actively recruiting Scouts entering or in middle school. Our Scouts come from all parts of Chapel Hill, and some from Durham and Pittsboro. Please send an email (below) or fill out an online application with the link on the right.
Only
very general information is contained on this page. Detailed
information may only be found on the Troop 820 troopwebhost page, which
is password protected. If you are a member of the Troop or a parent,
please use the link below to send an e-mail and request an invitation
to the troopwebhost group. Thanks.
|
Occoneechee Council Website
National BSA Website
Eno River District Web Page
Troop 820 Cookbook
Online Application
|
|
|
|
|
|
|
Troop
820 has approximately 18 scouts, ages 11-17, and several Assistant
Scoutmasters. Our patrols are the Barracudas, Cobras, and Leadership. We have
an active monthly camping program.
|
|
|
189 Scouts have become Eagle Scouts through Troop 820. Please click on the link below for a complete list as well
as some helpful information for those Scouts pursuing Eagle.
|
|
|
Troop
820 has been served by twelve Scoutmasters since being founded on March
19, 1969. They are: Harry Jensen, Bill Chapell, Jim Wells, John Humber,
John Overton, Alex Bell, Doug Leigh, Tim Taft, Bob Verne, Thor
Fjellstedt, Alfred Reid, and Ed Bedford.
|
|
|
Page Last Updated: January 27, 2023
|
<EMAIL_ADDRESS>|
|
HOME | Troop 820 Photos | Troop 820 Eagle Scouts | Aims & Methods of Scouting
|
|


Currently I am a student at Ecole des Ponts ParisTech engineering school, where I study Mathematics and Computer Science. I have a passion for web development and I would like to enhance my knowledge in Data Science, software development and design.
As a member of the Junior Business of Ecole des Ponts ParisTech, I am in charge of proposing IT solutions to companies and recruiting students to build them.
I designed an intranet to make it easy for Prepaya to share internal documents.
As an intern, I learned how to fix air compressors in the water bottle factory.
Using geometrical mathematics, we studied the behavior of electrons in crystals and could link it to the Quantum Hall Effect
This project aimed at analyzing the impact of a road closure policy in Paris on the road network.
Our goal was to find out the best configuration of the traffic model to fit the behaviour of an autonomous vehicle.
Apart from being a web developer, I enjoy most of my time being outdoors. In the winter, I am an avid skier. During the warmer months, I am up to hiking and wakeboarding.

I am also an active member of the IT Club at Ecole Des Ponts ParisTech.
In this organization, I am in charge of maintaining applications
on the shool's servers and I deploy student's projects.


Lesson: Estimate Sums
Overview
Estimate Sums Teach students to use a number line to estimate the Sum.
MainContent
Number Line Estimation Using 5-Groups Give students a copy of the number line from 0 to 10. Have them use their pointer finger to show the shaded section from 0 to 5. Instruct students to point to the number 5 as the middle of the number line. Explain that 0 to 5 are shaded to show a “5-group.” For students who struggle, practice identifying single numbers as closer to 5 or 10 prior to moving on to estimating sums. Next, prompt students to estimate the sum of 6 + 3 using the number line as a visual guide. Ask students if the sum will be closer to 5 or 10. Have them explain their responses. Students may say that the 6 already pushed past 5, so several more jumps on the number line would get them close to 10. (The focus here should be purely on estimating, not adding.) Repeat this procedure with other problems. Challenge students to explain how the number line helps them to estimate the sum.
Rationale
The Challenge: Flexible Thinking Flexible thinking is difficult for many students. Estimation requires flexibility in thinking because students are not asked to provide the actual answer to a problem. Instead, they are asked to make predictions about possible answers. The uncertainty inherent to predictions requires students to consider many possibilities, which is a key aspect of flexible thinking. The Growth Opportunity: Building Estimation Skills Estimation is a key skill in mathematics. Using a number line can help students improve both estimation skills and flexibility in thinking. Representing numbers and the relationships between numbers on a number line is also an important intermediate step in mathematical understanding. Number lines help to bridge the gap between concrete understanding (such as counting and moving objects) and mental math. Being skilled at using a number line has been shown to be one of the most significant predictors of future success in math.
Lesson: Develop Fact Fluency With Addition
Overview
Develop Fact Fluency With Addition Provide frequent opportunities for students to practice fact retrieval.
MainContent
Addition Bingo A fun way to practice fact fluency is to play addition bingo. Give each student a bingo board. Instruct students to choose a number from 2 to 12 and write it in a random box on the board. Repeat until all boxes have been filled (without repeating any numbers). Pair up students and give each pair two dice. To play, Player A rolls the dice and adds the numbers together to find the sum. Player B should verify that the sum is correct. If students have the sum on their bingo boards, they can cover the square with a coin or other object. Students take turns until one player completes a row, column, or diagonal line and calls out “addition bingo.” Differentiate: For students who struggle with recalling addition facts, use oversize dice so they can count the dots as needed. Provide instruction on using a number line or other manipulatives to gradually diminish the use of counting and to work toward building their fluency.
Rationale
The Challenge: Calculation Fluency Fluency with mathematical procedures is a common area of struggle for students with learning and attention issues. Speed in computation is a significant predictor of a student’s performance in solving word problems: With faster computation comes better problem-solving performance. The Growth Opportunity: Fluency and Conceptual Understanding Opportunities to practice rapid recall of addition facts will further strengthen fluency. Families can play addition bingo at home to help students build fluency.
Lesson: Practice Counting Strategies
Overview
Practice Counting Strategies Review a progression of counting strategies. Start with “counting all” (a strategy that students are likely familiar with). Students count the first addend in an addition sentence, count the second addend, and then count both addends together. (If you choose to use the term “addend,” define it as “a number being added to another.”) For instance, for 4 + 2, students would count 1, 2, 3, 4, and then 1, 2, and finally 1, 2, 3, 4, 5, 6. Then progress to “counting on.” Students start with the first addend and then count on to include the second addend. Again, for 4 + 2, students would say 4, and then count on 5, 6. This makes counting more efficient, as it skips the step of counting each addend separately.
MainContent
Give each student 5 counters that are red on one side and yellow on the other (or similar manipulatives). Put the counters in a line with 3 showing the red side and 2 showing yellow. Review “counting all” by leading students in counting all the red counters. Tell students to touch each counter as they count: 1, 2, 3. Do the same with the yellow counters: 1, 2. Then, lead the class in “counting all” of the counters together: 1, 2, 3, 4, 5. Next, explain that the “counting on” strategy will save them time when they count. This time, use 6 counters to show 2 red counters + 4 yellow counters. Lead students in naming the first addend: 2. Instead of counting the yellow counters separately, “count on” to include them with the first set: 3, 4, 5, 6. Explain to students that they have added the two groups. Ask them how many counters they have in all. Reveal that students can be even faster at “counting on.” Teach them to start with the greater addend in the addition sentence. To add the same 2 red counters and 4 yellow counters as above (2 + 4), they should start with 4 and then count on 2 red counters: 5, 6. This helps students become even more efficient in their counting. As an extension or an exit ticket, have students flip the counters to show any combination of red and yellow counters that still total 6 in all (or any number you select). Have them model “counting on” for you.
Rationale
The Challenge: Understanding Counting Principles There are five principles to counting: Stable order One-to-one correspondence Cardinality Abstraction Order irrelevance Students who struggle with one or more of these principles can have difficulty learning addition. The Growth Opportunity: A Toolbox of Counting Strategies As students work with addition, they will have to fluidly combine counting principles, so it is helpful to practice them together. Developing a counting strategy, and then progressively using a more efficient strategy, helps students learn the counting principles needed for understanding addition.


ALIndexPath Class Reference
| Inherits from | NSObject |
|---|---|
| Declared in | ALIndexPath.h |
Overview
With the ALIndexPath the position of the Digit can be specified. Digits are sectioned in line and the position in the line.
positionInLine
The position of the digit in the line.
@property (nonatomic) NSInteger positionInLine
Declared In
ALIndexPath.h
– compare:
Compares two IndexPaths and returns the comparison result.
- (NSComparisonResult)compare:(id)object
Parameters
object |
An other IndexPath object to compare to. |
|---|
Return Value
The NSComparisonResult for the the 2 IndexPaths.
Declared In
ALIndexPath.h


Add a contact using the search bar at the top. Start a conversation with them using the button next to their name.


“I had the pleasure of being Agustina's client partner while designing an app for a new category of products - activity tracking smart glasses. She was a great resource for helping the team find a direction that was both user-friendly and functional. She was always willing to go out of her way to meet the team's expectations, while pushing back when necessary, and was very agile when unexpected directional changes occurred. Her testing methods were thorough and gave us confidence that we were shipping a product that people would love. Anyone would be lucky to have Agustina on their team.”
Kristi Gaudio - UX Design Researcher and Strategist @ The Shop | VSP Global
“Agustina is an absolute joy to work with. Dedicated, passionate, a very creative problem-solver and excellent communicator. I very much enjoyed working with her, and she delivered a final product that was far beyond my wildest and most unreasonable expectations. I would not hesitate to hire or work with her in any capacity, and hope I have the opportunity again myself someday.”
James Wirth - SEO Director @ Catalyst
“I worked closely with Agustina for about two months on a major product redesign. She is a jack of all trades - insightful researcher, creative designer, efficient project manager, savvy technologist, and overall consummate professional. Before this project I thought I had to be co-located with a design firm to get a quality product. Agustina proved me very wrong! Her skill, flexibility, and professionalism made it a breeze.”
Xander Mittman - Director of Product Management @ Salesforce
“Agustina is one of the best coworkers that I had. She's always very compromised with the project, looking at every detail and helping whenever she can to make things move forward.
When we worked together she was in charge of the UX and visual design of several projects.”
Roberto Dip - Software Engineer @ Haiku
“Few designers have the passion and thoroughness that I've seen Agustina pour into the projects she pursues. Her abilities to reflect on her craftsmanship and that of others, and to teach with humour, tact and enthusiasm, have made her my go-to designer for advice and guidance.
Extremely reliable and competent, rest assured she will make invaluable contributions to any team she joins.”


Ask the Magic 8 Ball
Speech to text conversion using JavaScript
Talk
Ask the 8 Ball
Clear
Press the Start button


| Informal standard Document: id3v2.3.0.html |
M. Nilsson 3rd February 1999 |
This document is an informal standard and replaces the ID3v2.2.0 standard. The informal standard is released so that implementors could have a set standard before a formal standard is set. The formal standard will use another version or revision number if not identical to what is described in this document. The contents in this document may change for clarifications but never for added or altered functionallity.
Distribution of this document is unlimited.
This document describes the ID3v2.3.0, which is a more developed version of the ID3v2 informal standard (version 2.2.0), evolved from the ID3 tagging system. The ID3v2 offers a flexible way of storing information about an audio file within itself to determine its origin and contents. The information may be technical information, such as equalisation curves, as well as related meta information, such as title, performer, copyright etc.
In the examples, text within "" is a text string exactly as it appears in a file. Numbers preceded with $ are hexadecimal and numbers preceded with % are binary. $xx is used to indicate a byte with unknown content. %x is used to indicate a bit with unknown content. The most significant bit (MSB) of a byte is called 'bit 7' and the least significant bit (LSB) is called 'bit 0'.
A tag is the whole tag described in this document. A frame is a block of information in the tag. The tag consists of a header, frames and optional padding. A field is a piece of information; one value, a string etc. A numeric string is a string that consists of the characters 0-9 only.
The two biggest design goals were to be able to implement ID3v2 without disturbing old software too much and that ID3v2 should be as flexible and expandable as possible.
The first criterion is met by the simple fact that the MPEG decoding software uses a syncsignal, embedded in the audiostream, to 'lock on to' the audio. Since the ID3v2 tag doesn't contain a valid syncsignal, no software will attempt to play the tag. If, for any reason, coincidence make a syncsignal appear within the tag it will be taken care of by the 'unsynchronisation scheme' described in section 5.
The second criterion has made a more noticeable impact on the design of the ID3v2 tag. It is constructed as a container for several information blocks, called frames, whose format need not be known to the software that encounters them. At the start of every frame there is an identifier that explains the frames' format and content, and a size descriptor that allows software to skip unknown frames.
If a total revision of the ID3v2 tag should be needed, there is a version number and a size descriptor in the ID3v2 header.
The ID3 tag described in this document is mainly targeted at files encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III and MPEG-2.5, but may work with other types of encoded audio.
The bitorder in ID3v2 is most significant bit first (MSB). The byteorder in multibyte numbers is most significant byte first (e.g. $12345678 would be encoded $12 34 56 78).
It is permitted to include padding after all the final frame (at the end of the ID3 tag), making the size of all the frames together smaller than the size given in the head of the tag. A possible purpose of this padding is to allow for adding a few additional frames or enlarge existing frames within the tag without having to rewrite the entire file. The value of the padding bytes must be $00.
The ID3v2 tag header, which should be the first information in the file, is 10 bytes as follows:
| ID3v2/file identifier | "ID3" | |
| ID3v2 version | $03 00 | |
| ID3v2 flags | %abc00000 | |
| ID3v2 size | 4 * %0xxxxxxx |
The first three bytes of the tag are always "ID3" to indicate that this is an ID3v2 tag, directly followed by the two version bytes. The first byte of ID3v2 version is it's major version, while the second byte is its revision number. In this case this is ID3v2.3.0. All revisions are backwards compatible while major versions are not. If software with ID3v2.2.0 and below support should encounter version three or higher it should simply ignore the whole tag. Version and revision will never be $FF.
The version is followed by one the ID3v2 flags field, of which currently only three flags are used.
a - Unsynchronisation
Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is used (see section 5 for details); a set bit indicates usage.
b - Extended header
The second bit (bit 6) indicates whether or not the header is followed by an extended header. The extended header is described in section 3.2.
c - Experimental indicator
The third bit (bit 5) should be used as an 'experimental indicator'. This flag should always be set when the tag is in an experimental stage.
All the other flags should be cleared. If one of these undefined flags are set that might mean that the tag is not readable for a parser that does not know the flags function.
The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7) is set to zero in every byte, making a total of 28 bits. The zeroed bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01.
The ID3v2 tag size is the size of the complete tag after unsychronisation, including padding, excluding the header but not excluding the extended header (total tag size - 10). Only 28 bits (representing up to 256MB) are used in the size description to avoid the introducuction of 'false syncsignals'.
An ID3v2 tag can be detected with the following pattern:
$49 44 33 yy yy xx zz zz zz zz
Where yy is less than $FF, xx is the 'flags' byte and zz is less than
$80.
The extended header contains information that is not vital to the correct parsing of the tag information, hence the extended header is optional.
| Extended header size | $xx xx xx xx | |
| Extended Flags | $xx xx | |
| Size of padding | $xx xx xx xx |
Where the 'Extended header size', currently 6 or 10 bytes, excludes itself. The 'Size of padding' is simply the total tag size excluding the frames and the headers, in other words the padding. The extended header is considered separate from the header proper, and as such is subject to unsynchronisation.
The extended flags are a secondary flag set which describes further attributes of the tag. These attributes are currently defined as follows
%x0000000 00000000
x - CRC data present
If this flag is set four bytes of CRC-32 data is appended to the extended header. The CRC should be calculated before unsynchronisation on the data between the extended header and the padding, i.e. the frames and only the frames.
| Total frame CRC | $xx xx xx xx |
As the tag consists of a tag header and a tag body with one or more frames, all the frames consists of a frame header followed by one or more fields containing the actual information. The layout of the frame header:
| Frame ID | $xx xx xx xx (four characters) | |
| Size | $xx xx xx xx | |
| Flags | $xx xx |
The frame ID made out of the characters capital A-Z and 0-9. Identifiers beginning with "X", "Y" and "Z" are for experimental use and free for everyone to use, without the need to set the experimental bit in the tag header. Have in mind that someone else might have used the same identifier as you. All other identifiers are either used or reserved for future use.
The frame ID is followed by a size descriptor, making a total header size of ten bytes in every frame. The size is calculated as frame size excluding frame header (frame size - 10).
In the frame header the size descriptor is followed by two flags bytes. These flags are described in section 3.3.1.
There is no fixed order of the frames' appearance in the tag, although it is desired that the frames are arranged in order of significance concerning the recognition of the file. An example of such order: UFID, TIT2, MCDI, TRCK ...
A tag must contain at least one frame. A frame must be at least 1 byte big, excluding the header.
If nothing else is said a string is represented as ISO-8859-1 characters in the range $20 - $FF. Such strings are represented as <text string>, or <full text string> if newlines are allowed, in the frame descriptions. All Unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order.
All numeric strings and URLs are always encoded as ISO-8859-1. Terminated strings are terminated with $00 if encoded with ISO-8859-1 and $00 00 if encoded as unicode. If nothing else is said newline character is forbidden. In ISO-8859-1 a new line is represented, when allowed, with $0A only. Frames that allow different types of text encoding have a text encoding description byte directly after the frame size. If ISO-8859-1 is used this byte should be $00, if Unicode is used it should be $01. Strings dependent on encoding is represented as <text string according to encoding>, or <full text string according to encoding> if newlines are allowed. Any empty Unicode strings which are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).
The three byte language field is used to describe the language of the frame's content, according to ISO-639-2.
All URLs may be relative, e.g. "picture.png", "../doc.txt".
If a frame is longer than it should be, e.g. having more fields than specified in this document, that indicates that additions to the frame have been made in a later version of the ID3v2 standard. This is reflected by the revision number in the header of the tag.
In the frame header the size descriptor is followed by two flags bytes. All unused flags must be cleared. The first byte is for 'status messages' and the second byte is for encoding purposes. If an unknown flag is set in the first byte the frame may not be changed without the bit cleared. If an unknown flag is set in the second byte it is likely to not be readable. The flags field is defined as follows.
%abc00000 %ijk00000
a - Tag alter preservation
This flag tells the software what to do with this frame if it is unknown and the tag is altered in any way. This applies to all kinds of alterations, including adding more padding and reordering the frames.
| 0 | Frame should be preserved. |
| 1 | Frame should be discarded. |
b - File alter preservation
This flag tells the software what to do with this frame if it is unknown and the file, excluding the tag, is altered. This does not apply when the audio is completely replaced with other audio data.
| 0 | Frame should be preserved. |
| 1 | Frame should be discarded. |
c - Read only
This flag, if set, tells the software that the contents of this frame is intended to be read only. Changing the contents might break something, e.g. a signature. If the contents are changed, without knowledge in why the frame was flagged read only and without taking the proper means to compensate, e.g. recalculating the signature, the bit should be cleared.
i - Compression
This flag indicates whether or not the frame is compressed.
| 0 | Frame is not compressed. |
| 1 | Frame is compressed using zlib with 4 bytes for 'decompressed size' appended to the frame header. |
j - Encryption
This flag indicates wether or not the frame is enrypted. If set one byte indicating with which method it was encrypted will be appended to the frame header. See section 4.26. for more information about encryption method registration.
| 0 | Frame is not encrypted. |
| 1 | Frame is encrypted. |
k - Grouping identity
This flag indicates whether or not this frame belongs in a group with other frames. If set a group identifier byte is added to the frame header. Every frame with the same group identifier belongs to the same group.
| 0 | Frame does not contain group information |
| 1 | Frame contains group information |
Some flags indicates that the frame header is extended with additional information. This information will be added to the frame header in the same order as the flags indicating the additions. I.e. the four bytes of decompressed size will preceed the encryption method byte. These additions to the frame header, while not included in the frame header size but are included in the 'frame size' field, are not subject to encryption or compression.
The default settings for the frames described in this document can be divided into the following classes. The flags may be set differently if found more suitable by the software.
1. Discarded if tag is altered, discarded if file is altered.
None.
2. Discarded if tag is altered, preserved if file is altered.
None.
3. Preserved if tag is altered, discarded if file is altered.
ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ
4. Preserved if tag is altered, preserved if file is altered.
The rest of the frames.
The following frames are declared in this draft.
This frame's purpose is to be able to identify the audio file in a database that may contain more information relevant to the content. Since standardisation of such a database is beyond this document, all frames begin with a null-terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific database implementation. Questions regarding the database should be sent to the indicated email address. The URL should not be used for the actual database queries. The string "http://www.id3.org/dummy/ufid.html" should be used for tests. Software that isn't told otherwise may safely remove such frames. The 'Owner identifier' must be non-empty (more than just a termination). The 'Owner identifier' is then followed by the actual identifier, which may be up to 64 bytes. There may be more than one "UFID" frame in a tag, but only one with the same 'Owner identifier'.
| <Header for 'Unique file identifier', ID: "UFID"> | |
| Owner identifier | <text string> $00 |
| Identifier | <up to 64 bytes binary data> |
The text information frames are the most important frames, containing information like artist, album and more. There may only be one text information frame of its kind in an tag. If the textstring is followed by a termination ($00 (00)) all the following information should be ignored and not be displayed. All text frame identifiers begin with "T". Only text frame identifiers begin with "T", with the exception of the "TXXX" frame. All the text information frames have the following format:
| <Header for 'Text information frame', ID: "T000" - "TZZZ", excluding "TXXX" described in 4.2.2.> | |
| Text encoding | $xx |
| Information | <text string according to encoding> |
| RX | Remix |
| CR | Cover |
| MPG | MPEG Audio | |
| /1 | MPEG 1/2 layer I | |
| /2 | MPEG 1/2 layer II | |
| /3 | MPEG 1/2 layer III | |
| /2.5 | MPEG 2.5 | |
| /AAC | Advanced audio compression | |
| VQF | Transform-domain Weighted Interleave Vector Quantization | |
| PCM | Pulse Code Modulated audio |
| DIG | Other digital media | |
| /A | Analog transfer from media | |
| ANA | Other analog media | |
| /WAC | Wax cylinder | |
| /8CA | 8-track tape cassette | |
| CD | CD | |
| /A | Analog transfer from media | |
| /DD | DDD | |
| /AD | ADD | |
| /AA | AAD | |
| LD | Laserdisc | |
| /A | Analog transfer from media | |
| TT | Turntable records | |
| /33 | 33.33 rpm | |
| /45 | 45 rpm | |
| /71 | 71.29 rpm | |
| /76 | 76.59 rpm | |
| /78 | 78.26 rpm | |
| /80 | 80 rpm | |
| MD | MiniDisc | |
| /A | Analog transfer from media | |
| DAT | DAT | |
| /A | Analog transfer from media | |
| /1 | standard, 48 kHz/16 bits, linear | |
| /2 | mode 2, 32 kHz/16 bits, linear | |
| /3 | mode 3, 32 kHz/12 bits, nonlinear, low speed | |
| /4 | mode 4, 32 kHz/12 bits, 4 channels | |
| /5 | mode 5, 44.1 kHz/16 bits, linear | |
| /6 | mode 6, 44.1 kHz/16 bits, 'wide track' play | |
| DCC | DCC | |
| /A | Analog transfer from media | |
| DVD | DVD | |
| /A | Analog transfer from media | |
| TV | Television | |
| /PAL | PAL | |
| /NTSC | NTSC | |
| /SECAM | SECAM | |
| VID | Video | |
| /PAL | PAL | |
| /NTSC | NTSC | |
| /SECAM | SECAM | |
| /VHS | VHS | |
| /SVHS | S-VHS | |
| /BETA | BETAMAX | |
| RAD | Radio | |
| /FM | FM | |
| /AM | AM | |
| /LW | LW | |
| /MW | MW | |
| TEL | Telephone | |
| /I | ISDN | |
| MC | MC (normal cassette) | |
| /4 | 4.75 cm/s (normal speed for a two sided cassette) | |
| /9 | 9.5 cm/s | |
| /I | Type I cassette (ferric/normal) | |
| /II | Type II cassette (chrome) | |
| /III | Type III cassette (ferric chrome) | |
| /IV | Type IV cassette (metal) | |
| REE | Reel | |
| /9 | 9.5 cm/s | |
| /19 | 19 cm/s | |
| /38 | 38 cm/s | |
| /76 | 76 cm/s | |
| /I | Type I cassette (ferric/normal) | |
| /II | Type II cassette (chrome) | |
| /III | Type III cassette (ferric chrome) | |
| /IV | Type IV cassette (metal) |
| <Header for 'User defined text information frame', ID: "TXXX"> | |
| Text encoding | $xx |
| Description | <text string according to encoding> $00 (00) |
| Value | <text string according to encoding> |
With these frames dynamic data such as webpages with touring information, price information or plain ordinary news can be added to the tag. There may only be one URL link frame of its kind in an tag, except when stated otherwise in the frame description. If the textstring is followed by a termination ($00 (00)) all the following information should be ignored and not be displayed. All URL link frame identifiers begins with "W". Only URL link frame identifiers begins with "W". All URL link frames have the following format:
| <Header for 'URL link frame', ID: "W000" - "WZZZ", excluding "WXXX" described in 4.3.2.> | |
| URL | <text string> |
This frame is intended for URL links concerning the audiofile in a similar way to the other "W"-frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual URL. The URL is always encoded with ISO-8859-1. There may be more than one "WXXX" frame in each tag, but only one with the same description.
| <Header for 'User defined URL link frame', ID: "WXXX"> | |
| Text encoding | $xx |
| Description | <text string according to encoding> $00 (00) |
| URL | <text string> |
Since there might be a lot of people contributing to an audio file in various ways, such as musicians and technicians, the 'Text information frames' are often insufficient to list everyone involved in a project. The 'Involved people list' is a frame containing the names of those involved, and how they were involved. The body simply contains a terminated string with the involvement directly followed by a terminated string with the involvee followed by a new involvement and so on. There may only be one "IPLS" frame in each tag.
| <Header for 'Involved people list', ID: "IPLS"> | |
| Text encoding | $xx |
| People list strings | <text strings according to encoding> |
This frame is intended for music that comes from a CD, so that the CD can be identified in databases such as the CDDB. The frame consists of a binary dump of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and then 8 bytes/track on the CD plus 8 bytes for the 'lead out' making a maximum of 804 bytes. The offset to the beginning of every track on the CD should be described with a four bytes absolute CD-frame address per track, and not with absolute time. This frame requires a present and valid "TRCK" frame, even if the CD's only got one track. There may only be one "MCDI" frame in each tag.
| <Header for 'Music CD identifier', ID: "MCDI"> | |
| CD TOC | <binary data> |
This frame allows synchronisation with key events in a song or sound. The header is:
| <Header for 'Event timing codes', ID: "ETCO"> | |
| Time stamp format | $xx |
Where time stamp format is:
$01 Absolute time, 32 bit sized, using MPEG frames as unit
$02 Absolute time, 32 bit sized, using milliseconds as unit
Abolute time means that every stamp contains the time from the beginning of the file.
Followed by a list of key events in the following format:
| Type of event | $xx |
| Time stamp | $xx (xx ...) |
The 'Time stamp' is set to zero if directly at the beginning of the sound or after the previous event. All events should be sorted in chronological order. The type of event is as follows:
| $00 | padding (has no meaning) |
| $01 | end of initial silence |
| $02 | intro start |
| $03 | mainpart start |
| $04 | outro start |
| $05 | outro end |
| $06 | verse start |
| $07 | refrain start |
| $08 | interlude start |
| $09 | theme start |
| $0A | variation start |
| $0B | key change |
| $0C | time change |
| $0D | momentary unwanted noise (Snap, Crackle & Pop) |
| $0E | sustained noise |
| $0F | sustained noise end |
| $10 | intro end |
| $11 | mainpart end |
| $12 | verse end |
| $13 | refrain end |
| $14 | theme end |
| $15-$DF | reserved for future use |
| $E0-$EF | not predefined sync 0-F |
| $F0-$FC | reserved for future use |
| $FD | audio end (start of silence) |
| $FE | audio file ends |
| $FF | one more byte of events follows (all the following bytes with the value $FF have the same function) |
Terminating the start events such as "intro start" is not required. The 'Not predefined sync's ($E0-EF) are for user events. You might want to synchronise your music to something, like setting of an explosion on-stage, turning on your screensaver etc.
There may only be one "ETCO" frame in each tag.
To increase performance and accuracy of jumps within a MPEG audio file, frames with timecodes in different locations in the file might be useful. The ID3v2 frame includes references that the software can use to calculate positions in the file. After the frame header is a descriptor of how much the 'frame counter' should increase for every reference. If this value is two then the first reference points out the second frame, the 2nd reference the 4th frame, the 3rd reference the 6th frame etc. In a similar way the 'bytes between reference' and 'milliseconds between reference' points out bytes and milliseconds respectively.
Each reference consists of two parts; a certain number of bits, as defined in 'bits for bytes deviation', that describes the difference between what is said in 'bytes between reference' and the reality and a certain number of bits, as defined in 'bits for milliseconds deviation', that describes the difference between what is said in 'milliseconds between reference' and the reality. The number of bits in every reference, i.e. 'bits for bytes deviation'+'bits for milliseconds deviation', must be a multiple of four. There may only be one "MLLT" frame in each tag.
| <Header for 'Location lookup table', ID: "MLLT"> | |
| MPEG frames between reference | $xx xx |
| Bytes between reference | $xx xx xx |
| Milliseconds between reference | $xx xx xx |
| Bits for bytes deviation | $xx |
| Bits for milliseconds dev. | $xx |
Then for every reference the following data is included;
| Deviation in bytes | %xxx.... |
| Deviation in milliseconds | %xxx.... |
For a more accurate description of the tempo of a musical piece this frame might be used. After the header follows one byte describing which time stamp format should be used. Then follows one or more tempo codes. Each tempo code consists of one tempo part and one time part. The tempo is in BPM described with one or two bytes. If the first byte has the value $FF, one more byte follows, which is added to the first giving a range from 2 - 510 BPM, since $00 and $01 is reserved. $00 is used to describe a beat-free time period, which is not the same as a music-free time period. $01 is used to indicate one single beat-stroke followed by a beat-free period.
The tempo descriptor is followed by a time stamp. Every time the tempo in the music changes, a tempo descriptor may indicate this for the player. All tempo descriptors should be sorted in chronological order. The first beat-stroke in a time-period is at the same time as the beat description occurs. There may only be one "SYTC" frame in each tag.
| <Header for 'Synchronised tempo codes', ID: "SYTC"> | |
| Time stamp format | $xx |
| Tempo data | <binary data> |
Where time stamp format is:
$01 Absolute time, 32 bit sized, using MPEG frames as unit
$02 Absolute time, 32 bit sized, using milliseconds as unit
Abolute time means that every stamp contains the time from the beginning of the file.
This frame contains the lyrics of the song or a text transcription of other vocal activities. The head includes an encoding descriptor and a content descriptor. The body consists of the actual text. The 'Content descriptor' is a terminated string. If no descriptor is entered, 'Content descriptor' is $00 (00) only. Newline characters are allowed in the text. There may be more than one 'Unsynchronised lyrics/text transcription' frame in each tag, but only one with the same language and content descriptor.
| <Header for 'Unsynchronised lyrics/text transcription', ID: "USLT"> | |
| Text encoding | $xx |
| Language | $xx xx xx |
| Content descriptor | <text string according to encoding> $00 (00) |
| Lyrics/text | <full text string according to encoding> |
This is another way of incorporating the words, said or sung lyrics, in the audio file as text, this time, however, in sync with the audio. It might also be used to describing events e.g. occurring on a stage or on the screen in sync with the audio. The header includes a content descriptor, represented with as terminated textstring. If no descriptor is entered, 'Content descriptor' is $00 (00) only.
| <Header for 'Synchronised lyrics/text', ID: "SYLT"> | |
| Text encoding | $xx |
| Language | $xx xx xx |
| Time stamp format | $xx |
| Content type | $xx |
| Content descriptor | <text string according to encoding> $00 (00) |
| Encoding: | $00 | ISO-8859-1 character set is used => $00 is sync identifier. |
| $01 | Unicode character set is used => $00 00 is sync identifier. |
| Content type: | $00 | is other |
| $01 | is lyrics | |
| $02 | is text transcription | |
| $03 | is movement/part name (e.g. "Adagio") | |
| $04 | is events (e.g. "Don Quijote enters the stage") | |
| $05 | is chord (e.g. "Bb F Fsus") | |
| $06 | is trivia/'pop up' information |
Time stamp format is:
$01 Absolute time, 32 bit sized, using MPEG frames as unit
$02 Absolute time, 32 bit sized, using milliseconds as unit
Abolute time means that every stamp contains the time from the beginning of the file.
The text that follows the frame header differs from that of the unsynchronised lyrics/text transcription in one major way. Each syllable (or whatever size of text is considered to be convenient by the encoder) is a null terminated string followed by a time stamp denoting where in the sound file it belongs. Each sync thus has the following structure:
| Terminated text to be synced (typically a syllable) | |
| Sync identifier (terminator to above string) | $00 (00) |
| Time stamp | $xx (xx ...) |
The 'time stamp' is set to zero or the whole sync is omitted if located directly at the beginning of the sound. All time stamps should be sorted in chronological order. The sync can be considered as a validator of the subsequent string.
Newline ($0A) characters are allowed in all "SYLT" frames and should be used after every entry (name, event etc.) in a frame with the content type $03 - $04.
A few considerations regarding whitespace characters: Whitespace separating words should mark the beginning of a new word, thus occurring in front of the first syllable of a new word. This is also valid for new line characters. A syllable followed by a comma should not be broken apart with a sync (both the syllable and the comma should be before the sync).
An example: The "USLT" passage
"Strangers in the night" $0A "Exchanging glances"
would be "SYLT" encoded as:
"Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx xx "glan" $00 xx xx "ces" $00 xx xx
There may be more than one "SYLT" frame in each tag, but only one with the same language and content descriptor.
This frame is indended for any kind of full text information that does not fit in any other frame. It consists of a frame header followed by encoding, language and content descriptors and is ended with the actual comment as a text string. Newline characters are allowed in the comment text string. There may be more than one comment frame in each tag, but only one with the same language and content descriptor.
| <Header for 'Comment', ID: "COMM"> | |
| Text encoding | $xx |
| Language | $xx xx xx |
| Short content descrip. | <text string according to encoding> $00 (00) |
| The actual text | <full text string according to encoding> |
This is a more subjective function than the previous ones. It allows the user to say how much he wants to increase/decrease the volume on each channel while the file is played. The purpose is to be able to align all files to a reference volume, so that you don't have to change the volume constantly. This frame may also be used to balance adjust the audio. If the volume peak levels are known then this could be described with the 'Peak volume right' and 'Peak volume left' field. If Peakvolume is not known these fields could be left zeroed or, if no other data follows, be completely omitted. There may only be one "RVAD" frame in each tag.
| <Header for 'Relative volume adjustment', ID: "RVAD"> | |
| Increment/decrement | %00xxxxxx |
| Bits used for volume descr. | $xx |
| Relative volume change, right | $xx xx (xx ...) |
| Relative volume change, left | $xx xx (xx ...) |
| Peak volume right | $xx xx (xx ...) |
| Peak volume left | $xx xx (xx ...) |
In the increment/decrement field bit 0 is used to indicate the right channel and bit 1 is used to indicate the left channel. 1 is increment and 0 is decrement.
The 'bits used for volume description' field is normally $10 (16 bits) for MPEG 2 layer I, II and III and MPEG 2.5. This value may not be $00. The volume is always represented with whole bytes, padded in the beginning (highest bits) when 'bits used for volume description' is not a multiple of eight.
This datablock is then optionally followed by a volume definition for the left and right back channels. If this information is appended to the frame the first two channels will be treated as front channels. In the increment/decrement field bit 2 is used to indicate the right back channel and bit 3 for the left back channel.
| Relative volume change, right back | $xx xx (xx ...) |
| Relative volume change, left back | $xx xx (xx ...) |
| Peak volume right back | $xx xx (xx ...) |
| Peak volume left back | $xx xx (xx ...) |
If the center channel adjustment is present the following is appended to the existing frame, after the left and right back channels. The center channel is represented by bit 4 in the increase/decrease field.
| Relative volume change, center | $xx xx (xx ...) |
| Peak volume center | $xx xx (xx ...) |
If the bass channel adjustment is present the following is appended to the existing frame, after the center channel. The bass channel is represented by bit 5 in the increase/decrease field.
| Relative volume change, bass | $xx xx (xx ...) |
| Peak volume bass | $xx xx (xx ...) |
This is another subjective, alignment frame. It allows the user to predefine an equalisation curve within the audio file. There may only be one "EQUA" frame in each tag.
| <Header of 'Equalisation', ID: "EQUA"> | |
| Adjustment bits | $xx |
The 'adjustment bits' field defines the number of bits used for representation of the adjustment. This is normally $10 (16 bits) for MPEG 2 layer I, II and III and MPEG 2.5. This value may not be $00.
This is followed by 2 bytes + ('adjustment bits' rounded up to the nearest byte) for every equalisation band in the following format, giving a frequency range of 0 - 32767Hz:
| Increment/decrement | %x (MSB of the Frequency) |
| Frequency | (lower 15 bits) |
| Adjustment | $xx (xx ...) |
The increment/decrement bit is 1 for increment and 0 for decrement. The equalisation bands should be ordered increasingly with reference to frequency. All frequencies don't have to be declared. The equalisation curve in the reading software should be interpolated between the values in this frame. Three equal adjustments for three subsequent frequencies. A frequency should only be described once in the frame.
Yet another subjective one. You may here adjust echoes of different kinds. Reverb left/right is the delay between every bounce in ms. Reverb bounces left/right is the number of bounces that should be made. $FF equals an infinite number of bounces. Feedback is the amount of volume that should be returned to the next echo bounce. $00 is 0%, $FF is 100%. If this value were $7F, there would be 50% volume reduction on the first bounce, 50% of that on the second and so on. Left to left means the sound from the left bounce to be played in the left speaker, while left to right means sound from the left bounce to be played in the right speaker.
'Premix left to right' is the amount of left sound to be mixed in the right before any reverb is applied, where $00 id 0% and $FF is 100%. 'Premix right to left' does the same thing, but right to left. Setting both premix to $FF would result in a mono output (if the reverb is applied symmetric). There may only be one "RVRB" frame in each tag.
| <Header for 'Reverb', ID: "RVRB"> | |
| Reverb left (ms) | $xx xx |
| Reverb right (ms) | $xx xx |
| Reverb bounces, left | $xx |
| Reverb bounces, right | $xx |
| Reverb feedback, left to left | $xx |
| Reverb feedback, left to right | $xx |
| Reverb feedback, right to right | $xx |
| Reverb feedback, right to left | $xx |
| Premix left to right | $xx |
| Premix right to left | $xx |
This frame contains a picture directly related to the audio file. Image format is the MIME type and subtype for the image. In the event that the MIME media type name is omitted, "image/" will be implied. The "image/png" or "image/jpeg" picture format should be used when interoperability is wanted. Description is a short description of the picture, represented as a terminated textstring. The description has a maximum length of 64 characters, but may be empty. There may be several pictures attached to one file, each in their individual "APIC" frame, but only one with the same content descriptor. There may only be one picture with the picture type declared as picture type $01 and $02 respectively. There is the possibility to put only a link to the image file by using the 'MIME type' "-->" and having a complete URL instead of picture data. The use of linked files should however be used sparingly since there is the risk of separation of files.
| <Header for 'Attached picture', ID: "APIC"> | |
| Text encoding | $xx |
| MIME type | <text string> $00 |
| Picture type | $xx |
| Description | <text string according to encoding> $00 (00) |
| Picture data | <binary data> |
| Picture type: | $00 | Other |
| $01 | 32x32 pixels 'file icon' (PNG only) | |
| $02 | Other file icon | |
| $03 | Cover (front) | |
| $04 | Cover (back) | |
| $05 | Leaflet page | |
| $06 | Media (e.g. lable side of CD) | |
| $07 | Lead artist/lead performer/soloist | |
| $08 | Artist/performer | |
| $09 | Conductor | |
| $0A | Band/Orchestra | |
| $0B | Composer | |
| $0C | Lyricist/text writer | |
| $0D | Recording Location | |
| $0E | During recording | |
| $0F | During performance | |
| $10 | Movie/video screen capture | |
| $11 | A bright coloured fish | |
| $12 | Illustration | |
| $13 | Band/artist logotype | |
| $14 | Publisher/Studio logotype |
In this frame any type of file can be encapsulated. After the header, 'Frame size' and 'Encoding' follows 'MIME type' represented as as a terminated string encoded with ISO-8859-1. The filename is case sensitive and is encoded as 'Encoding'. Then follows a content description as terminated string, encoded as 'Encoding'. The last thing in the frame is the actual object. The first two strings may be omitted, leaving only their terminations. There may be more than one "GEOB" frame in each tag, but only one with the same content descriptor.
| <Header for 'General encapsulated object', ID: "GEOB"> | |
| Text encoding | $xx |
| MIME type | <text string> $00 |
| Filename | <text string according to encoding> $00 (00) |
| Content description | |
| Encapsulated object | <binary data> |
This is simply a counter of the number of times a file has been played. The value is increased by one every time the file begins to play. There may only be one "PCNT" frame in each tag. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger. The counter must be at least 32-bits long to begin with.
| <Header for 'Play counter', ID: "PCNT"> | |
| Counter | $xx xx xx xx (xx ...) |
The purpose of this frame is to specify how good an audio file is. Many interesting applications could be found to this frame such as a playlist that features better audiofiles more often than others or it could be used to profile a person's taste and find other 'good' files by comparing people's profiles. The frame is very simple. It contains the email address to the user, one rating byte and a four byte play counter, intended to be increased with one for every time the file is played. The email is a terminated string. The rating is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no personal counter is wanted it may be omitted. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger in the same away as the play counter ("PCNT"). There may be more than one "POPM" frame in each tag, but only one with the same email address.
| <Header for 'Popularimeter', ID: "POPM"> | |
| Email to user | <text string> $00 |
| Rating | $xx |
| Counter | $xx xx xx xx (xx ...) |
Sometimes the server from which a audio file is streamed is aware of transmission or coding problems resulting in interruptions in the audio stream. In these cases, the size of the buffer can be recommended by the server using this frame. If the 'embedded info flag' is true (1) then this indicates that an ID3 tag with the maximum size described in 'Buffer size' may occur in the audiostream. In such case the tag should reside between two MPEG frames, if the audio is MPEG encoded. If the position of the next tag is known, 'offset to next tag' may be used. The offset is calculated from the end of tag in which this frame resides to the first byte of the header in the next. This field may be omitted. Embedded tags are generally not recommended since this could render unpredictable behaviour from present software/hardware.
For applications like streaming audio it might be an idea to embed tags into the audio stream though. If the clients connects to individual connections like HTTP and there is a possibility to begin every transmission with a tag, then this tag should include a 'recommended buffer size' frame. If the client is connected to a arbitrary point in the stream, such as radio or multicast, then the 'recommended buffer size' frame should be included in every tag. Every tag that is picked up after the initial/first tag is to be considered as an update of the previous one. E.g. if there is a "TIT2" frame in the first received tag and one in the second tag, then the first should be 'replaced' with the second.
The 'Buffer size' should be kept to a minimum. There may only be one "RBUF" frame in each tag.
| <Header for 'Recommended buffer size', ID: "RBUF"> | |
| Buffer size | $xx xx xx |
| Embedded info flag | %0000000x |
| Offset to next tag | $xx xx xx xx |
This frame indicates if the actual audio stream is encrypted, and by whom. Since standardisation of such encrypion scheme is beyond this document, all "AENC" frames begin with a terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific encrypted audio file. Questions regarding the encrypted audio should be sent to the email address specified. If a $00 is found directly after the 'Frame size' and the audiofile indeed is encrypted, the whole file may be considered useless.
After the 'Owner identifier', a pointer to an unencrypted part of the audio can be specified. The 'Preview start' and 'Preview length' is described in frames. If no part is unencrypted, these fields should be left zeroed. After the 'preview length' field follows optionally a datablock required for decryption of the audio. There may be more than one "AENC" frames in a tag, but only one with the same 'Owner identifier'.
| <Header for 'Audio encryption', ID: "AENC"> | |
| Owner identifier | <text string> $00 |
| Preview start | $xx xx |
| Preview length | $xx xx |
| Encryption info | <binary data> |
To keep space waste as low as possible this frame may be used to link information from another ID3v2 tag that might reside in another audio file or alone in a binary file. It is recommended that this method is only used when the files are stored on a CD-ROM or other circumstances when the risk of file seperation is low. The frame contains a frame identifier, which is the frame that should be linked into this tag, a URL field, where a reference to the file where the frame is given, and additional ID data, if needed. Data should be retrieved from the first tag found in the file to which this link points. There may be more than one "LINK" frame in a tag, but only one with the same contents. A linked frame is to be considered as part of the tag and has the same restrictions as if it was a physical part of the tag (i.e. only one "RVRB" frame allowed, whether it's linked or not).
| <Header for 'Linked information', ID: "LINK"> | |
| Frame identifier | $xx xx xx |
| URL | <text string> $00 |
| ID and additional data | <text string(s)> |
Frames that may be linked and need no additional data are "IPLS", "MCID", "ETCO", "MLLT", "SYTC", "RVAD", "EQUA", "RVRB", "RBUF", the text information frames and the URL link frames.
The "TXXX", "APIC", "GEOB" and "AENC" frames may be linked with the content descriptor as additional ID data.
The "COMM", "SYLT" and "USLT" frames may be linked with three bytes of language descriptor directly followed by a content descriptor as additional ID data.
This frame delivers information to the listener of how far into the audio stream he picked up; in effect, it states the time offset of the first frame in the stream. The frame layout is:
| <Head for 'Position synchronisation', ID: "POSS"> | |
| Time stamp format | $xx |
| Position | $xx (xx ...) |
Where time stamp format is:
$01 Absolute time, 32 bit sized, using MPEG frames as unit
$02 Absolute time, 32 bit sized, using milliseconds as unit
and position is where in the audio the listener starts to receive, i.e. the beginning of the next frame. If this frame is used in the beginning of a file the value is always 0. There may only be one "POSS" frame in each tag.
This frame contains a brief description of the terms of use and ownership of the file. More detailed information concerning the legal terms might be available through the "WCOP" frame. Newlines are allowed in the text. There may only be one "USER" frame in a tag.
| <Header for 'Terms of use frame', ID: "USER"> | |
| Text encoding | $xx |
| Language | $xx xx xx |
| The actual text | <text string according to encoding> |
The ownership frame might be used as a reminder of a made transaction or, if signed, as proof. Note that the "USER" and "TOWN" frames are good to use in conjunction with this one. The frame begins, after the frame ID, size and encoding fields, with a 'price payed' field. The first three characters of this field contains the currency used for the transaction, encoded according to ISO-4217 alphabetic currency code. Concatenated to this is the actual price payed, as a numerical string using "." as the decimal separator. Next is an 8 character date string (YYYYMMDD) followed by a string with the name of the seller as the last field in the frame. There may only be one "OWNE" frame in a tag.
| <Header for 'Ownership frame', ID: "OWNE"> | |
| Text encoding | $xx |
| Price payed | <text string> $00 |
| Date of purch. | <text string> |
| Seller | <text string according to encoding> |
This frame enables several competing offers in the same tag by bundling all needed information. That makes this frame rather complex but it's an easier solution than if one tries to achieve the same result with several frames. The frame begins, after the frame ID, size and encoding fields, with a price string field. A price is constructed by one three character currency code, encoded according to ISO-4217 alphabetic currency code, followed by a numerical value where "." is used as decimal seperator. In the price string several prices may be concatenated, seperated by a "/" character, but there may only be one currency of each type.
The price string is followed by an 8 character date string in the format YYYYMMDD, describing for how long the price is valid. After that is a contact URL, with which the user can contact the seller, followed by a one byte 'received as' field. It describes how the audio is delivered when bought according to the following list:
| $00 | Other |
| $01 | Standard CD album with other songs |
| $02 | Compressed audio on CD |
| $03 | File over the Internet |
| $04 | Stream over the Internet |
| $05 | As note sheets |
| $06 | As note sheets in a book with other sheets |
| $07 | Music on other media |
| $08 | Non-musical merchandise |
Next follows a terminated string with the name of the seller followed by a terminated string with a short description of the product. The last thing is the ability to include a company logotype. The first of them is the 'Picture MIME type' field containing information about which picture format is used. In the event that the MIME media type name is omitted, "image/" will be implied. Currently only "image/png" and "image/jpeg" are allowed. This format string is followed by the binary picture data. This two last fields may be omitted if no picture is to attach.
| <Header for 'Commercial frame', ID: "COMR"> | |
| Text encoding | $xx |
| Price string | <text string> $00 |
| Valid until | <text string> |
| Contact URL | <text string> $00 |
| Received as | $xx |
| Name of seller | <text string according to encoding> $00 (00) |
| Description | <text string according to encoding> $00 (00) |
| Picture MIME type | <string> $00 |
| Seller logo | <binary data> |
To identify with which method a frame has been encrypted the encryption method must be registered in the tag with this frame. The 'Owner identifier' is a null-terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific encryption method. Questions regarding the encryption method should be sent to the indicated email address. The 'Method symbol' contains a value that is associated with this method throughout the whole tag. Values below $80 are reserved. The 'Method symbol' may optionally be followed by encryption specific data. There may be several "ENCR" frames in a tag but only one containing the same symbol and only one containing the same owner identifier. The method must be used somewhere in the tag. See section 3.3.1, flag j for more information.
| <Header for 'Encryption method registration', ID: "ENCR"> | |
| Owner identifier | <text string> $00 |
| Method symbol | $xx |
| Encryption data | <binary data> |
This frame enables grouping of otherwise unrelated frames. This can be used when some frames are to be signed. To identify which frames belongs to a set of frames a group identifier must be registered in the tag with this frame. The 'Owner identifier' is a null-terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this grouping. Questions regarding the grouping should be sent to the indicated email address. The 'Group symbol' contains a value that associates the frame with this group throughout the whole tag. Values below $80 are reserved. The 'Group symbol' may optionally be followed by some group specific data, e.g. a digital signature. There may be several "GRID" frames in a tag but only one containing the same symbol and only one containing the same owner identifier. The group symbol must be used somewhere in the tag. See section 3.3.1, flag j for more information.
| <Header for 'Group ID registration', ID: "GRID"> | |
| Owner identifier | <text string> $00 |
| Group symbol | $xx |
| Group dependent data | <binary data> |
This frame is used to contain information from a software producer that its program uses and does not fit into the other frames. The frame consists of an 'Owner identifier' string and the binary data. The 'Owner identifier' is a null-terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for the frame. Questions regarding the frame should be sent to the indicated email address. The tag may contain more than one "PRIV" frame but only with different contents. It is recommended to keep the number of "PRIV" frames as low as possible.
| <Header for 'Private frame', ID: "PRIV"> | |
| Owner identifier | <text string> $00 |
| The private data | <binary data> |
The only purpose of the 'unsynchronisation scheme' is to make the ID3v2 tag as compatible as possible with existing software. There is no use in 'unsynchronising' tags if the file is only to be processed by new software. Unsynchronisation may only be made with MPEG 2 layer I, II and III and MPEG 2.5 files.
Whenever a false synchronisation is found within the tag, one zeroed byte is inserted after the first false synchronisation byte. The format of a correct sync that should be altered by ID3 encoders is as follows:
%11111111 111xxxxx
And should be replaced with:
%11111111 00000000 111xxxxx
This has the side effect that all $FF 00 combinations have to be altered, so they won't be affected by the decoding process. Therefore all the $FF 00 combinations have to be replaced with the $FF 00 00 combination during the unsynchronisation.
To indicate usage of the unsynchronisation, the first bit in 'ID3 flags' should be set. This bit should only be set if the tag contains a, now corrected, false synchronisation. The bit should only be clear if the tag does not contain any false synchronisations.
Do bear in mind, that if a compression scheme is used by the encoder, the unsynchronisation scheme should be applied *afterwards*. When decoding a compressed, 'unsynchronised' file, the 'unsynchronisation scheme' should be parsed first, decompression afterwards.
If the last byte in the tag is $FF, and there is a need to eliminate false synchronisations in the tag, at least one byte of padding should be added.
Copyright © Martin Nilsson 1998. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that a reference to this document is included on all such copies and derivative works. However, this document itself may not be modified in any way and reissued as the original document.
The limited permissions granted above are perpetual and will not be revoked.

[CDDB] Compact Disc Data Base
<url:http://www.cddb.com>
[ID3v2] Martin Nilsson, "ID3v2 informal standard".
<url:http://www.id3.org/id3v2-00.txt>
[ISO-639-2] ISO/FDIS 639-2.
Codes for the representation of names of languages, Part 2: Alpha-3 code. Technical committee / subcommittee: TC 37 / SC 2
[ISO-4217] ISO 4217:1995.
Codes for the representation of currencies and funds. Technical committee / subcommittee: TC 68
[ISO-8859-1] ISO/IEC DIS 8859-1.
8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2
[ISRC] ISO 3901:1986
International Standard Recording Code (ISRC). Technical committee / subcommittee: TC 46 / SC 9
[JFIF] JPEG File Interchange Format, version 1.02
<url:http://www.w3.org/Graphics/JPEG/jfif.txt>
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
<url:ftp://ftp.isi.edu/in-notes/rfc2045.txt>
[MPEG] ISO/IEC 11172-3:1993.
Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s, Part 3: Audio. Technical committee / subcommittee: JTC 1 / SC 29
and
ISO/IEC 13818-3:1995
Generic coding of moving pictures and associated audio information, Part 3: Audio. Technical committee / subcommittee: JTC 1 / SC 29
and
ISO/IEC DIS 13818-3
Generic coding of moving pictures and associated audio information, Part 3: Audio (Revision of ISO/IEC 13818-3:1995)
[PNG] Portable Network Graphics, version 1.0
<url:http://www.w3.org/TR/REC-png-multi.html>
[UNICODE] ISO/IEC 10646-1:1993.
Universal Multiple-Octet Coded Character Set (UCS), Part 1: Architecture and Basic Multilingual Plane. Technical committee / subcommittee: JTC 1 / SC 2
<url:http://www.unicode.org>
[URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource Locators (URL).", RFC 1738, December 1994.
<url:ftp://ftp.isi.edu/in-notes/rfc1738.txt>
[ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
<url:ftp://ftp.isi.edu/in-notes/rfc1950.txt>
The following genres is defined in ID3v1
0.Blues 1.Classic Rock 2.Country 3.Dance 4.Disco 5.Funk 6.Grunge 7.Hip-Hop 8.Jazz 9.Metal 10.New Age 11.Oldies 12.Other 13.Pop 14.R&B 15.Rap 16.Reggae 17.Rock 18.Techno 19.Industrial 20.Alternative 21.Ska 22.Death Metal 23.Pranks 24.Soundtrack 25.Euro-Techno 26.Ambient 27.Trip-Hop 28.Vocal 29.Jazz+Funk 30.Fusion 31.Trance 32.Classical 33.Instrumental 34.Acid 35.House 36.Game 37.Sound Clip 38.Gospel 39.Noise 40.AlternRock 41.Bass 42.Soul 43.Punk 44.Space 45.Meditative 46.Instrumental Pop 47.Instrumental Rock 48.Ethnic 49.Gothic 50.Darkwave 51.Techno-Industrial 52.Electronic 53.Pop-Folk 54.Eurodance 55.Dream 56.Southern Rock 57.Comedy 58.Cult 59.Gangsta 60.Top 40 61.Christian Rap 62.Pop/Funk 63.Jungle 64.Native American 65.Cabaret 66.New Wave 67.Psychadelic 68.Rave 69.Showtunes 70.Trailer 71.Lo-Fi 72.Tribal 73.Acid Punk 74.Acid Jazz 75.Polka 76.Retro 77.Musical 78.Rock & Roll 79.Hard Rock |
The following genres are Winamp extensions
80.Folk 81.Folk-Rock 82.National Folk 83.Swing 84.Fast Fusion 85.Bebob 86.Latin 87.Revival 88.Celtic 89.Bluegrass 90.Avantgarde 91.Gothic Rock 92.Progressive Rock 93.Psychedelic Rock 94.Symphonic Rock 95.Slow Rock 96.Big Band 97.Chorus 98.Easy Listening 99.Acoustic 100.Humour 101.Speech 102.Chanson 103.Opera 104.Chamber Music 105.Sonata 106.Symphony 107.Booty Bass 108.Primus 109.Porn Groove 110.Satire 111.Slow Jam 112.Club 113.Tango 114.Samba 115.Folklore 116.Ballad 117.Power Ballad 118.Rhythmic Soul 119.Freestyle 120.Duet 121.Punk Rock 122.Drum Solo 123.A capella 124.Euro-House 125.Dance Hall |
Written by
Martin Nilsson
Rydsvägen 246 C. 30
S-584 34 Linköping
Sweden
Email<EMAIL_ADDRESS>Edited by
Dirk Mahoney
57 Pechey Street
Chermside Q
Australia 4032
Email<EMAIL_ADDRESS>Johan Sundström
Alsättersgatan 5 A. 34
S-584 35 Linköping
Sweden
Email: johan@id3.org


tier_match
is the ultimate wrapper function in
fedmatch.
tier_match
puts together all of the
pieces from the package into one function, letting the user perform many
matches in one call. The function is excellent both as an exploratory
tool, while the user is still figuring out how they want to execute
their matches, and as a final matching tool that can be used in
production code.
‘tiers’ of a match are useful because there are hierarchies of matches. An exact name match between two companies is a higher-quality match than a fuzzy match, and fuzzy matches with various levels of cleaning can be different levels of quality.
The syntax of tier_match
is providing a core list of
arguments to the function itself, and then passing a named list to the
tier match. Each element in this list is itself a list, each of which is
a tier to match on, and it contains all of the arguments necessary for
that tier. All of these arguments will be passed to ‘merge_plus’ in
sequence, and each of the matches from each tier are saved and
combined.
<- list(
tier_list a = build_tier(match_type = "exact"),
b = build_tier(match_type = "fuzzy"),
c = build_tier(match_type = "multivar", multivar_settings = build_multivar_settings(
logit = NULL, missing = FALSE, wgts = 1,
compare_type = "stringdist", blocks = NULL, blocks.x = NULL, blocks.y = NULL,
top = 1, threshold = NULL
))
)# tier_list
This list will perform three matches: ‘a’, an exact match; ‘b’, a
fuzzy match, and ‘c’, a multivar match. We can get a bit fancier and add
more settings to each, if we’d like. Remember that each element of each
tier has to be an argument for merge_plus
.
<- list(
tier_list_v2 a = build_tier(match_type = "exact", clean = TRUE),
b = build_tier(match_type = "fuzzy", clean = TRUE,
fuzzy_settings = build_fuzzy_settings(method = "wgt_jaccard",
maxDist = .7,
nthread = 1),
clean_settings = build_clean_settings(remove_words = TRUE)),
c = build_tier(match_type = "multivar",
multivar_settings = build_multivar_settings(
logit = NULL, missing = FALSE, wgts = 1,
compare_type = "stringdist", blocks = NULL, blocks.x = NULL, blocks.y = NULL,
top = 1, threshold = NULL
)) )
Let’s take a look at the rest of the syntax for
tier_match
:
<- tier_match(corp_data1, corp_data2,
result by.x = "Company", by.y = "Name",
unique_key_1 = "unique_key_1", unique_key_2 = "unique_key_2",
tiers = tier_list_v2, takeout = "neither", verbose = TRUE,
score_settings = build_score_settings(score_var_x = "Company",
score_var_y = "Name",
wgts = 1,
score_type = "stringdist")
)#> Matching tier 'a'...
#> Time elapsed: 0 secs.
#> Matching tier 'b'...
#> Time elapsed: 0.01 secs.
#> Matching tier 'c'...
#> Time elapsed: 0.02 secs.
There are two types of arguments for tier_match
: those
that can be passed to merge_plus
, and those that are unique
to tier_match
. If anything of the merge_plus
arguments are listed in tier_match
directly (rather than in
tier_list
), those arguments are used in every tier. In this
example, we are always matching on ‘Company’ and ‘Name,’ so those are
placed in the arguments for tier_match directly. The arguments unique to
tier_match
and their defaults are:
tiers
is the tier list create by iterations of
build_tier()
. Required, no default.takeout
is a character vector, either “neither”,
“both”, “data1”, or “data2”. These settings describe whether or not to
take out matches in between each tier, and if so, what dataset to remove
the matches for.verbose
is a boolean. If TRUE
, prints tier
names and time taken to match each tier.The other arguments are all present in merge_plus
, see
documentation there for details.
The result for tier_match is a list with 4 items: the matched dataset, the unmatched data, and a match evaluation. Here’s what the matches look like:
$matches[1:5]
result#> Company Country State SIC Revenue unique_key_1 country state_code
#> 1: walmart USA OH 3300 485 1 USA OH
#> 2: walmart USA OH 3300 485 1 USA OH
#> 3: Walmart USA OH 3300 485 1 USA OH
#> 4: Bershire Hataway USA 2222 223 2 USA NE
#> 5: apple USA CA 3384 215 3 USA CA
#> SIC_code earnings unique_key_2 Name matchscore Company_score
#> 1: 3380 490,000 1 walmart 1.0000000 1.0000000
#> 2: 3380 490,000 1 walmart 1.0000000 1.0000000
#> 3: 3380 490,000 1 Walmart 1.0000000 1.0000000
#> 4: 2220 220,000 2 Bershire Hathaway 0.9882353 0.9882353
#> 5: NA 220,000 3 apple computer 0.8714286 0.8714286
#> tier Company_compare multivar_score
#> 1: a NA NA
#> 2: b NA NA
#> 3: c 1.0000000 1.0000000
#> 4: c 0.9882353 0.9882353
#> 5: b NA NA
As you can see, the matches dataset has a column called ‘tier’ that
indicates which tier the match was from. It also adds any additional
columns added by the matching process. In this example, we see
‘Company_score’, created from the from the post-hoc scoring;
‘wgt_jaccard_sim’, the Weighted Jaccard similarity, created when using
the ‘wgt_jaccard’ setting of fuzzy_match
(see the
‘Fuzzy-matching’ vignette for more details); and ‘Company_compare’,
created from the multivar matching tier.
We also have a match evaluation, now filled out with more details broken down by tier:
$match_evaluation
result#> tier matches in_tier_unique_1 in_tier_unique_2 pct_matched_1 pct_matched_2
#> 1: a 2 2 2 0.2 0.2
#> 2: b 7 7 7 0.7 0.7
#> 3: c 10 10 9 1.0 0.9
#> 4: all 19 10 9 1.0 0.9
#> new_unique_1 new_unique_2
#> 1: 2 2
#> 2: 5 5
#> 3: 3 2
#> 4: NA NA
We can use this evaluation to figure out which tiers did the ‘best’ job matching, getting the most unique matches.


Cotton farmers target 300,000MT in 2020 - The Nation Newspaper
Juliana Agbo, Abuja
The National Cotton Association of Nigeria (NACOTAN) has said its members had increased their initial production of 200,000 metric tons to 300,000 metric tons for 2020, as they target to bring about 300,000 farmers on board.
The National President of NACOTAN, Mr. Anibe Achimugu, while speaking with journalists immediately after his re-election into the association, said before the intervention of the Central Bank of Nigeria (CBN) through the Anchor Borrowers Program, farmers were getting about 500 to 600kg per hectare, but with quality seeds from the ABP, it has increased to about 2 metric tons per hectare.
On cotton production, Achimugu said the association is not working in isolation, adding that they are working along with the Central Bank of Nigeria (CBN).
“Next year, we are targeting a minimum of 300,000 farmers, that alone even with one hectare or 1 ton per hectare, that is 300,000 metric tons”, he said.
“When I look back, I remember that the association was near comatose, there was no leadership structure, meetings were not being held, state chapters were left on their own, but I would like to think that since my coming on board, I have recognised and registered about 151,000 farmers; we have been able to participate effectively under the Anchor Borrowers Program, where each farmer got a minimum of N170,000 in input financing.
He said the NEC convened the meeting so that the state chairmen and secretaries of their association could strategise about aggregation, collection and recovery of loans from their members.
“CBN was here to motivate us to do the right thing, if we do the right thing; they said that 300,000 metric tons is only the beginning,” he said.