AI Coding Book

AI Coding Book — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

Learning automaton

A learning automaton is one type of machine learning algorithm studied since 1970s. Learning automata select their current action based on past experiences from the environment. It will fall into the range of reinforcement learning if the environment is stochastic and a Markov decision process (MDP) is used. == History == Research in learning automata can be traced back to the work of Michael Lvovitch Tsetlin in the early 1960s in the Soviet Union. Together with some colleagues, he published a collection of papers on how to use matrices to describe automata functions. Additionally, Tsetlin worked on reasonable and collective automata behaviour, and on automata games. Learning automata were also investigated by researches in the United States in the 1960s. However, the term learning automaton was not used until Narendra and Thathachar introduced it in a survey paper in 1974. == Definition == A learning automaton is an adaptive decision-making unit situated in a random environment that learns the optimal action through repeated interactions with its environment. The actions are chosen according to a specific probability distribution which is updated based on the environment response the automaton obtains by performing a particular action. With respect to the field of reinforcement learning, learning automata are characterized as policy iterators. In contrast to other reinforcement learners, policy iterators directly manipulate the policy π. Another example for policy iterators are evolutionary algorithms. Formally, Narendra and Thathachar define a stochastic automaton to consist of: a set X of possible inputs, a set Φ = { Φ1, ..., Φs } of possible internal states, a set α = { α1, ..., αr } of possible outputs, or actions, with r ≤ s, an initial state probability vector p(0) = ≪ p1(0), ..., ps(0) ≫, a computable function A which after each time step t generates p(t+1) from p(t), the current input, and the current state, and a function G: Φ → α which generates the output at each time step. In their paper, they investigate only stochastic automata with r = s and G being bijective, allowing them to confuse actions and states. The states of such an automaton correspond to the states of a "discrete-state discrete-parameter Markov process". At each time step t=0,1,2,3,..., the automaton reads an input from its environment, updates p(t) to p(t+1) by A, randomly chooses a successor state according to the probabilities p(t+1) and outputs the corresponding action. The automaton's environment, in turn, reads the action and sends the next input to the automaton. Frequently, the input set X = { 0,1 } is used, with 0 and 1 corresponding to a nonpenalty and a penalty response of the environment, respectively; in this case, the automaton should learn to minimize the number of penalty responses, and the feedback loop of automaton and environment is called a "P-model". More generally, a "Q-model" allows an arbitrary finite input set X, and an "S-model" uses the interval [0,1] of real numbers as X. A visualised demo/ Art Work of a single Learning Automaton had been developed by μSystems (microSystems) Research Group at Newcastle University. == Finite action-set learning automata == Finite action-set learning automata (FALA) are a class of learning automata for which the number of possible actions is finite or, in more mathematical terms, for which the size of the action-set is finite.
Read more →
Bare machine

In information technology, a bare machine (or bare-metal computer) is a computer which has no operating system. The software executed by a bare machine, commonly called a bare metal program or bare metal application, is designed to interact directly with hardware. Bare machines are widely used in embedded systems, particularly in cases where resources are limited or high performance is required. == Bare machine computing == Bare Machine Computing is a computing paradigm in which application software runs directly on a bare machine as a single, stand-alone executable, without an operating system or device drivers. The application software has direct access to hardware resources, and there is typically no distinction between user and kernel mode. It is self-managed software that boots, loads and runs without using any other software components. Bare metal programs are typically written in a close-to-hardware language such as C or assembly language. == Advantages == Typically, a bare-metal application will run faster, use less memory and be more power efficient than an equivalent program that relies on an operating system, due to the inherent overhead imposed by system calls. For example, hardware inputs and outputs are directly accessible to bare metal software, whereas they must usually be accessed through system calls when using an OS. It has no OS and therefore has no OS-related vulnerabilities. == Disadvantages == Bare metal applications typically require more effort to develop because operating system services such as memory management and task scheduling are not available. Debugging a bare-metal program may be complicated by factors such as: Lack of a standard output. The target machine may differ from the hardware used for program development (e.g., emulator, simulator). This forces setting up a way to load the bare-metal program onto the target (flashing), start the program execution and access the target resources. == Examples == === Early computers === Early computers, such as the PDP-11, allowed programmers to load a program, supplied in machine code, to RAM. The resulting operation of the program could be monitored by lights, and output derived from magnetic tape, print devices, or storage. Amdahl UTS's performance improves by 25% when run on bare metal without VM, the company said in 1986. === Embedded systems === Bare machine programming is a common practice in embedded systems, in which microcontrollers or microprocessors boot directly into monolithic, single-purpose software without loading an operating system. Such embedded software can vary in structure. For example, one such program paradigm, known as foreground-background or superloop architecture, consists of an infinite main loop in which each task is executed sequentially and must voluntarily return control back to the loop. The loop runs these cooperative background processes that are not time-critical, while interrupt service routines momentarily interrupt the loop to handle time-critical foreground tasks.
Read more →
Digital signage

Digital signage is a segment of electronic signage that uses digital display technologies to present multimedia content in both public and private environments. Content may include video, images, text, or interactive media and is typically displayed for purposes such as advertising, information dissemination, branding, or entertainment. Digital signage systems can be either networked or standalone. Networked systems are managed through centralized content management systems (CMS), often cloud-based, enabling remote updates, scheduling, real-time data integration, and dynamic content delivery. These systems may also incorporate audience analytics, IoT sensors, or AI-driven personalization. Standalone systems, by contrast, operate without a network connection. They rely on local media playback via USB drives, SD cards, or internal storage. These solutions are simpler and suitable for locations where connectivity is limited or content changes infrequently. == Applications of digital signage == Digital signage is widely used in transportation hubs, retail stores, restaurants, corporate buildings, hotels, educational institutions, healthcare facilities, and public spaces. One prominent application of digital signage is Digital Out-of-Home (DOOH) advertising, which leverages digital signage displays in public spaces to deliver targeted advertisements to people outside of their homes. DOOH has become a significant segment of digital signage, providing advertisers with a dynamic and contextually relevant way to engage with audiences. == Components == === Hardware components === Digital signage hardware includes the physical equipment used to show multimedia content in public and private spaces. ==== Display devices ==== Display devices are the most prominent components of a digital signage system, serving as the primary medium for presenting content. Display devices come in various technologies, such as LCD, LED, and OLED formats, each offering different advantages in terms of clarity, color reproduction, and energy efficiency. In addition to flat-panel displays, projectors are also commonly used in digital signage, particularly in large-scale settings. Projectors can cast large-format visuals onto walls, screens, or other surfaces, providing flexibility in display size and positioning. Screen sizes vary widely to suit different applications. Smaller panels are often used in kiosks and point-of-sale systems, while larger displays, such as video walls and projection surfaces, are deployed in venues like stadiums, auditoriums, and other public spaces. Many digital signage displays are also equipped with touchscreen capabilities, allowing for interactive applications. These interactive displays are commonly used in information kiosks, wayfinding systems, and self-service applications. ==== Playback devices ==== Playback devices are specialized hardware components that manage the storage, processing, and transmission of multimedia content to digital signage displays and projectors. They serve as the crucial link between the content management system (CMS) and the visual output, ensuring seamless playback of static images, video files, animated graphics, and real-time content, such as news feeds. Playback devices can be standalone units or integrated into display hardware using System-on-Chip (SoC) technology. The latter reduces hardware complexity and installation time, making the system more efficient. These devices support remote or local content updates, allowing digital signage operators to manage networks effectively. Content can be updated via cloud-based platforms for centralized control or through direct interfaces on-site, depending on the system's configuration and deployment requirements. ==== Mounting systems ==== Mounting systems provide structural support for digital signage displays, enabling deployment across diverse environments. Typical configurations include wall mounts, ceiling mounts, and floor stands each engineered to meet specific spatial and functional requirements. === Software components === Digital signage software is responsible for content creation, scheduling, and management. It enables users to manage and distribute content to one or more playback devices. ==== Software compatibility ==== Digital signage software supports various operating systems, including Android, Windows, Linux, iOS, tvOS, webOS, Tizen, ChromeOS, macOS, and others. This allows customers to choose the hardware and software solution that best suits their digital signage needs. == Interactivity == Interactivity in digital signage allows users to interact directly with displays using input methods like touch, gestures, voice, or proximity sensors. This feature enables real-time responses and personalized content, improving the user experience. Interactive digital signage is commonly used in places like retail, transportation, education, and public spaces to create engaging and informative interactions. Additionally, self-service kiosks are often integrated into interactive signage solutions, allowing users to perform tasks such as ordering products, checking in for flights, accessing information, or making payments. These kiosks empower users to complete transactions or obtain services independently, improving efficiency and convenience in high-traffic locations. == Audience measurement and context-aware content adaptation == === Audience measurement === Cameras can be integrated into digital signage systems to enable audience measurement. They are used to detect and count viewers, estimate demographics such as age and gender, measure dwell time and attention, and sometimes analyze emotional reactions using computer vision techniques. This process is valuable for understanding audience behavior and refining business strategies. Privacy concerns are addressed by anonymizing collected data and avoiding the storage of personally identifiable information. === Context-aware digital signage === Context-aware digital signage refers to systems that adjust content based on environmental or audience data. The infrastructure supporting context awareness, including sensors and analytics systems, also facilitates the collection of audience insights. While these insights may be primarily used for reporting, optimization, or planning future campaigns rather than immediate content adjustments, they play a crucial role in the overall context-aware ecosystem. ==== Contextual information ==== Contextual information in the realm of context-aware digital signage refers to data about the environment, audience, and other factors that influence how digital signage content is displayed. This information helps the system to deliver more relevant, timely, and personalized content to its audience. Contextual information can include, but is not limited to: Audience demographics — this can involve detecting the age, gender, or even emotional state of viewers through cameras or sensors. It helps tailor content to specific audience segments, improving engagement. Time and weather — the system may adjust content based on the time of day or current weather conditions. For example, weather-appropriate content (like a raincoat ad on a rainy day) or time-specific content (like dinner menu promotions in the evening) can be shown. Emergency information — in situations of emergency, systems can prioritize displaying urgent notifications such as fire alerts, disaster warnings, or evacuation instructions. This can be crucial for public safety in crowded environments or densely populated areas. The system may adapt content in real-time to inform and guide individuals to safety, offering location-specific instructions or emergency service contacts. == Challenges == === Display blindness === Digital signage in public spaces has been found to lose visibility, significantly diminishing its ability to capture attention. This issue, known as "Display Blindness", was identified by Müller et al. and refers to the phenomenon where digital advertisements are largely overlooked by passersby. Observations indicate that many of these advertisements fail to resonate with their audience, often being irrelevant or unengaging, which leads to passive reception and reduced interaction. == Comparison with print signage == Digital signage and traditional print signage serve similar purposes by delivering visual information to a target audience, but they differ significantly in terms of flexibility, cost, maintenance, and environmental impact. Digital signage is advantageous in low-light or nighttime environments, where its internal illumination ensures visibility without the need for external lighting, unlike printed signs, which may require additional fixtures to be seen after dark. === Content and flexibility === Digital signage allows for dynamic and real-time content updates, often controlled remotely through content management systems. This makes it well-suited for environments where information chan
Read more →
Digital cassettes

Digital audio cassette formats introduced to the professional audio and consumer markets: Digital Audio Tape (or DAT) is the most well-known, and had some success as an audio storage format among professionals and "prosumers" before the prices of hard drive and solid-state flash memory-based digital recording devices dropped in the late 1990s. Hard-drive recording has mostly made DAT obsolete, as hard disk recorders offer more editing versatility than tape, and easier importation into digital audio workstations (DAWs) and non-linear video editing (NLE) systems. Digital Compact Cassette was intended as a digital replacement for the mass-market analog cassette tape, but received very little attention or adaptation. Its failure is generally attributed to higher production costs than audio CDs, durability and indifferent reception by consumers. Digital video cassettes include: Betacam IMX (Sony) D-VHS (JVC) D1 (Sony) D2 (Sony) D3 D5 HD Digital-S D9 (JVC) Digital Betacam (Sony) Digital8 (Sony) DV HDV ProHD (JVC) MiniDV MicroMV == Analog cassettes used as digital data storage == Historically, the compact audio cassette which was originally designed for analog storage of music was used as an alternative to disk drives in the late 1970s and early 1980s to provide data storage for home computers. There is a number of unique and incompatible cassette tape data storage formats that all use the same analog compact audio cassette tape media. The ADAT system uses Super VHS tapes to record 8 synchronized digital audiotracks at once. There have also been several audio recording systems that used VHS video recorders as storage devices and video tape transports, generally by encoding the digital data to be recorded into an analog composite video signal (which resembles static) and then recording this to magnetic tape. These systems were often used as "mixdown" recorders, to record the finished mix from a multi-track recorder in preparation for the manufacture of a vinyl record, cassette tape, or CD. An example was the Dbx Model 700. Another example is the Sony PCM adaptor series. Several companies sold VHS backup solutions in the 1980s and 1990s where data was converted to a video image which was then saved onto a VHS tape. the Corvus "Mirror" ( U.S. patent 4380047A ) the Metrum Model 64 on S-VHS tape, the Danmere Backer tape backup system, the Alpha Microsystems Videotrax the Legacy Storage Systems International VAST (Variable Array Storage) the ArVid the Video Backup System Amiga, The S2 VLBI system at three NASA Deep Space Network complexes and over 20 other radio telescopes stores digital data on SVHS tapes.
Read more →
Monitoring as a service

Monitoring as a service (MaaS) is a cloud-based framework for the deployment of monitoring functionalities for various other services and applications within the cloud. The most common application for MaaS is online state monitoring, which continuously tracks certain states of applications, networks, systems, instances or any element that may be deployable within the cloud.
Read more →
Hydration (web development)

In web development, hydration or rehydration is a technique in which client-side JavaScript converts a web page that is static from the perspective of the web browser, delivered either through static rendering or server-side rendering, into a dynamic web page by attaching event handlers to the HTML elements in the DOM. Because the HTML is pre-rendered on a server, this allows for a fast "first contentful paint" (when useful data is first displayed to the user), but there is a period of time afterward where the page appears to be fully loaded and interactive, but is not until the client-side JavaScript is executed and event handlers have been attached. Frameworks that use hydration include Next.js and Nuxt. React v16.0 introduced a "hydrate" function, which hydrates an element, in its API. == Variations == === Streaming server-side rendering === Streaming server-side rendering allows one to send HTML in chunks that the browser can progressively render as it is received. This can provide a fast first paint and first contentful paint as HTML markup arrives to users faster. === Progressive rehydration === In progressive rehydration, individual pieces of a server-rendered application are “booted up” over time, rather than the current common approach of initializing the entire application at once. This can help reduce the amount of JavaScript required to make pages interactive, since client-side upgrading of low priority parts of the page can be deferred to prevent blocking the main thread. It can also help avoid one of the most common server-side rendering rehydration pitfalls, where a server-rendered DOM tree gets destroyed and then immediately rebuilt – most often because the initial synchronous client-side render required data that wasn't quite ready, perhaps awaiting Promise resolution. === Partial rehydration === Partial rehydration has proven difficult to implement. This approach is an extension of the idea of progressive rehydration, where the individual pieces (components/views/trees) to be progressively rehydrated are analyzed and those with little interactivity or no reactivity are identified. For each of these mostly-static parts, the corresponding JavaScript code is then transformed into inert references and decorative functionality, reducing their client-side footprint to near-zero. The partial hydration approach comes with its own issues and compromises. It poses some interesting challenges for caching, and client-side navigation means it cannot be assumed that server-rendered HTML for inert parts of the application will be available without a full page load. One framework that supports partial rehydration is Elder.js, which is based on Svelte. === Trisomorphic rendering === Trisomorphic rendering is a technique which uses streaming server-side rendering for initial/non-JavaScript navigations, and then uses service workers to take on rendering of HTML for navigations after it has been installed. This can keep cached components and templates up to date and enables SPA-style navigations for rendering new views in the same session. This approach works best when one can share the same templating and routing code between the server, client page, and service worker.
Read more →
SitePal

SitePal is a speaking avatar platform for small and medium-sized businesses developed by Oddcast. SitePal allows users to deploy "virtual employees" on websites that can welcome visitors, guide them around the site and answer questions. The use of SitePal on commercial websites has been controversial because many visitors report finding them annoying. Some research has shown that they can increase sales in comparison to using static photographs. == Development == The technology used was the result of more than 4 years of research at Stanford University. The research was based on a literature review and other previous work in the field of artificial intelligence research. The SitePal AI option uses the AIML programming language, which is partially editable by users. This allows web designers to simulate normal human conversation by using keywords or key phrases that the bot can respond to. == Features == The company provides web designers with options to customize the chosen avatar. A large selection of faces, clothing, hair, backgrounds, voices and other details are available. If a web designer wants to use a particular face, Sitepal can create one from a photo. Thus, a mascot or a known face can be simulated. == Speech == Sitepal avatars talk through text-to-speech (tts) software. A short paragraph can be written (up to 900 characters) and the text-to-speech engine will compile the actual speech, which can be reproduced and edited. The tts engine is not perfect, but it comes close to actual speech and is easy to understand. Tts can be further enhanced by some commands, like /laugh and /loud which make the avatar laugh or talk loud. Even pronunciation is possible. The web designer can record and upload his or her own audio messages. Alternatively Sitepal offers professional voice acting service at extra cost. == User interaction == The company provides 5 options for visitor interaction: No interaction. The avatar simply says a pre-fixed message. FAQ mode. Questions can be configured, which are clickable and the user can hear the answer. Lead mode. The avatar prompts the user to type his email and short message, so it can be sent to the webmaster (usually used on a "contact us" page) Chatbot mode. The avatar greets the user, and he can type his questions and have a conversation with the bot. With predetermined replies, this can work as an FAQ as well. API customization. Experienced programmers can make their avatar interact with their website, making it talk when the user clicks on a link or when other triggers occur. Even dual avatar conversations can be created, like a talk show. == Posting options == The company provides five options for posting the avatar: Embed in webpage (via javascript) Embed in HTML Send by email Publish to eBay Embed in Flash == Criticism == Early reviews, such as one by Troy Dreier published in PC World in 2002 were positive and described SitePal as: "an engagingly simple and personal tool, and the price is reasonable for what it adds to a site". Although Dreier did note that the program had "bugs that suggested it hadn't been tested thoroughly". In more recent years, reaction to SitePal has been much more negative with reviews such as Tom Spring writing in a PC World review citing SitePal ads and described his reaction as "Not so nice". Paul Bissex, writing in E-Scribe News described SitePal as "heinous... and embarrassing if anyone is within earshot...they creep me out" == Research on effectiveness == In one single-website research project Anita Campbell had half the visitors to Small Business Trends see a SitePal and the other half see just a static photograph. Over 11,000 visitors the SitePal avatar improved sign-up for a newsletter 144% over the control condition.
Read more →
HTTP cookie

An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small block of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session. Cookies serve useful and sometimes essential functions on the web. They enable web servers to store stateful information (such as items added in the shopping cart in an online store) on the user's device or to track the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past). They can also be used to save information that the user previously entered into form fields, such as names, addresses, passwords, and payment card numbers for subsequent use. Authentication cookies are commonly used by web servers to authenticate that a user is logged in, and with which account they are logged in. Without the cookie, users would need to authenticate themselves by logging in on each page containing sensitive information that they wish to access. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by an attacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting and cross-site request forgery for examples). Tracking cookies, and especially third-party tracking cookies, are commonly used as ways to compile long-term records of individuals' browsing histories — a potential privacy concern that prompted European and U.S. lawmakers to take action in 2011. European law requires that all websites targeting European Union member states gain "informed consent" from users before storing non-essential cookies on their device. == Background == === Origin of the name === The term cookie was coined by web-browser programmer Lou Montulli. It was derived from the term magic cookie, which is a packet of data a program receives and sends back unchanged, used by Unix programmers. === History === Magic cookies were already used in computing when computer programmer Lou Montulli had the idea of using them in web communications in June 1994. At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for MCI. Vint Cerf and John Klensin represented MCI in technical discussions with Netscape Communications. MCI did not want its servers to have to retain partial transaction states, which led them to ask Netscape to find a way to store that state in each user's computer instead. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart. Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on 13 October 1994, supported cookies. The first use of cookies (out of the labs) was checking whether visitors to the Netscape website had already visited the site. Montulli applied for a patent for the cookie technology in 1995, which was granted in 1998. Support for cookies was integrated with Internet Explorer in version 2, released in October 1995. The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of their presence. The public learned about cookies after the Financial Times published an article about them on 12 February 1996. In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997. The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the Internet Engineering Task Force (IETF) was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by Brian Behlendorf and David Kristol respectively. But the group, headed by Kristol himself and Lou Montulli, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default. At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000. RFC 2965 added a Set-Cookie2 header field, which informally came to be called "RFC 2965-style cookies" as opposed to the original Set-Cookie header field which was called "Netscape-style cookies". Set-Cookie2 was seldom used, however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world. No modern browser recognizes the Set-Cookie2 header field. == Terminology == === Session cookie === A session cookie (also known as an in-memory cookie, transient cookie or non-persistent cookie) exists only in temporary memory while the user navigates a website. Session cookies expire or are deleted when the user closes the web browser. Session cookies are identified by the browser by the absence of an expiration date assigned to them. === Persistent cookie === A persistent cookie expires at a specific date or after a specific length of time. For the persistent cookie's lifespan set by its creator, its information will be transmitted to the server every time the user visits the website that it belongs to, or every time the user views a resource belonging to that website from another website (such as an advertisement). For this reason, persistent cookies are sometimes referred to as tracking cookies because they can be used by advertisers to record information about a user's web browsing habits over an extended period of time. Persistent cookies are also used for reasons such as keeping users logged into their accounts on websites, to avoid re-entering login credentials at every visit. (See § Uses, below.) === Secure cookie === A secure cookie can only be transmitted over an encrypted connection (i.e. HTTPS). They cannot be transmitted over unencrypted connections (i.e. HTTP). This makes the cookie less likely to be exposed to cookie theft via eavesdropping. A cookie is made secure by adding the Secure flag to the cookie. === Http-only cookie === An http-only cookie cannot be accessed by client-side APIs, such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS). However, the cookie remains vulnerable to cross-site tracing (XST) and cross-site request forgery (CSRF) attacks. A cookie is given this characteristic by adding the HttpOnly flag to the cookie. === Same-site cookie === In 2016 Google Chrome version 51 introduced a new kind of cookie with attribute SameSite with possible values of Strict, Lax or None. With attribute SameSite=Strict, the browsers would only send cookies to a target domain that is the same as the origin domain. This would effectively mitigate cross-site request forgery (CSRF) attacks. With SameSite=Lax, browsers would send cookies with requests to a target domain even it is different from the origin domain, but only for safe requests such as GET (POST is unsafe) and not third-party cookies (inside iframe). Attribute SameSite=None would allow third-party (cross-site) cookies, however, most browsers require secure attribute on SameSite=None cookies. The Same-site cookie is incorporated into a new RFC draft for "Cookies: HTTP State Management Mechanism" to update RFC 6265 (if approved). Chrome, Firefox, and Edge started to support Same-site cookies. The key of rollout is the treatment of existing cookies without the SameSite attribute defined, Chrome has been treating those existing cookies as if SameSite=None, this would let all website/applications run as before. Google intended to change that default to SameSite=Lax in Chrome 80 planned to be released in February 2020, but due to potential for breakage of those applications/websites that rely on third-party/cross-site cookies and COVID-19 circumstances, Google postponed this change to Chrome 84. === Supercookie === A supercookie is a cookie with an origin of a top-level domain (such as .com) or a public suffix (such as .co.uk). Ordinary cookies, by contrast, have an origin of a specific domain name, such as ex
Read more →
Dhammin

Dhammin (Arabic: ضمّن) is a political platform that manages candidates' electoral campaigns for the National Assembly, Municipal Council or Cooperative Society councils of Kuwait. The platform was founded by Abdullah Al-Salloum and it is, according to news reports and interviews, the first within the field to apply distributed-systems' methodologies.
Read more →
Pull technology

Pull coding or client pull is a style of network communication, where the initial request for data originates from the client, and then is responded to by the server. The reverse is known as push technology, where the server pushes data to clients. Pull requests form the foundation of network computing, where many clients request data from centralized servers. Pull is used extensively on the Internet for HTTP page requests from websites. A push can also be simulated using multiple pulls within a short amount of time. For example, when pulling POP3 email messages from a server, a client can make regular pull requests, every few minutes. To the user, the email then appears to be pushed, as emails appear to arrive close to real-time. A trade-off of this system is that it places a heavier load on both the server and network to function correctly. Many web feeds, such as RSS are technically pulled by the client. With RSS, the user's RSS reader polls the server periodically for new content; the server does not send information to the client unrequested. This continual polling is inefficient and has contributed to the shutdown or reduction of several popular RSS feeds that could not handle the bandwidth. For solving this problem, the WebSub protocol, as another example of a push code, was devised. Podcasting is specifically a pull technology. When a new podcast episode is published to an RSS feed, it sits on the server until it is requested by a feed reader, mobile podcasting app, or directory. Directories such as Apple Podcasts (iTunes), The Blubrry Directory, and many apps' directories request the RSS feed periodically to update the Podcast's listing on those platforms. Subscribers to those RSS feeds via app or reader will get the episodes when they request the RSS feed next time, independent of when the directory listing updates.
Read more →
Digital heritage

The Charter on the Preservation of Digital Heritage of UNESCO defines digital heritage as embracing "cultural, educational, scientific and administrative resources, as well as technical, legal, medical and other kinds of information created digitally, or converted into digital form from existing analogue resources". Digital heritage also includes the use of digital media in the service of understanding and preserving cultural or natural heritage. The digitization of both cultural heritage and Natural heritage serves to enable the permanent access of current and future generations to culturally important objects ranging from literature and paintings to flora, fauna, or habitats. It is also used in the preservation and access of objects with enduring or significant historical, scientific, or cultural value including buildings, archeological sites, and natural phenomena. The main idea is the transformation of a material object into a virtual copy. It should not be confused with digital humanities, which uses digitizing technology to specifically help with research. There have been several debates concerning the efficiency of the process of digitizing heritage. Some of the drawbacks refer to the deterioration and technological obsolescence due to the lack of funding for archival materials and underdeveloped policies that would regulate such a process. Another main social debate has taken place around the restricted accessibility due to the digital divide that exists around the world. Nevertheless, new technologies enable easy, instant and cross boarder access to the digitized work. Many of these technologies include spatial and surveying technology to gain aerial or 3D images. Digital heritage is also used to monitor cultural heritage sites over years to help with preservation, maintenance, and sustainable tourism. It aims to observe any changes, diseases, or deterioration that may occur on objects. == Cultural and natural heritage == Digital Heritage that is not born-digital can be divided into two separate groups—digital cultural heritage and digital natural heritage. Digital cultural heritage is the maintenance or preservation of cultural objects through digitization. These are objects, in some cases entire cities, that are considered of cultural importance. These objects are sometimes able to be digitized or physically represented in minute detail. Digital cultural heritage also includes intangible heritage. These are things such as "oral traditions, customs, value systems, skills, traditional dances, diets, performances" and other unique features of a culture. Intangible heritage is particularly vulnerable to destruction due to urbanization. There are several projects and programs which concentrate on digital cultural heritage. One such project is Mapping Gothic France, which aims to document and preserve cathedrals across France using images, VR tours, laser scans, and panoramas. This allows for scientific and historical study and preservation of the cathedrals and also provides detailed access to the sites for anyone in the world. The aim of projects like these is to help with the preservation and restoration of cultural objects. After the fire at Notre-Dame de Paris in 2019, digital scans are a major component in the ongoing restoration. Digital natural heritage pertains to objects of natural heritage that are considered of cultural, scientific, or aesthetic importance. Digital heritage in this instance is used not only to grant access to these objects, but to monitor any changes over time, such as with plant or animal habitats. Geographic information systems are a form of technology that is used primarily in the study of natural heritage. Western Australia has one such digital heritage project where they have created a digital repository of native plants important to both the region and the Aboriginal people. This is in order to protect and preserve the important biological heritage of Western Australia. == Educational impact == The digitization of these heritage objects has impacts around the world and across many disciplines. The increase of digital items means that people, especially the youth, are able to learn about new objects and cultures online through various media. They provide viewers with a more in-depth experience with an item or place, instead of just an image. The media is also able to be curated to age- or educational-level appropriateness, making learning easier. Some of the technology used in education, especially in museums, includes mobile apps, virtual reality, social media, and video games. Cultural heritage institutions are using this technology to try to expand access, increase appreciation for these items, and to gain new viewpoints on their collections. Digital heritage also helps scientists, archeologists, or other historians and specialists collect data on these objects, providing more information on the objects and the past. Digital Heritage is still currently being studied and improved by several sectors invested in cultural and intellectual preservation. It is particularly of interest to museums, governments, and academic institutions. Research by these groups are creating new concepts, methodologies, and techniques for the implementation of digital heritage to protect this type of cultural and natural heritage. As new technologies are created, museums and other heritage institutions are provided with more ways of disseminating their information and engaging with the public. A lack of resources within certain groups may still hinder everyone from accessing digital heritage. == Technologies used == The digitization of cultural heritage is attained through several means. Some of the main technology used is spatial and surveying technology. Space archaeological technology - Observations from space satellites are non-intrusive and can be integrated with other technologies on the ground. It is used to photograph vast areas of earth and help with research. Remnants of ancient civilizations or other human objects are also able to be spotted via satellite imaging. Unmanned aerial vehicles - UAV, such as drones, are commonly used in digitization of cultural heritage objects. The Great Wall of China is one such site that has been digitized and analyzed through unmanned aerial vehicle investigation. The resulting images, 3-D scans, maps, and other data are used to evaluate and maintain the Great Wall. Laser Scanning - Laser scanning is used to scan an area and recreate spatially accurate depictions, such as a 3D model. Virtual and Augmented Reality - VR is used primarily for education but does have uses for reconstruction and research. It is used to provide users with an immersive experience, as though they are actually at the site. Geographic Information systems - GIS are used primarily to study objects and sites over time. It is also important in studying the socioeconomic status of the past. 3D Modeling - 3D modeling has become more widely used due to an increase in technology that works specifically with heritage sites. It is often used in tandem with GIS to reconstruct objects for restoration, documentation, preservation, and educational purposes. Data is collected using satellite or other aerial imaging and ground-based imaging. There is some concern about the accuracy and authenticity of these types of digital reconstructions and their effects on the sites themselves. A major barrier to digital heritage is the amount of resources it takes to undertake such projects, such as money, time, and technology. Money and the lack of qualified personnel are two that are considered the most obstructive. This is especially an issue in less developed areas or within underfunded groups such as minorities. == Virtual heritage == A particular branch of digital heritage, known as "virtual heritage", is formed by the use of information technology with the aim of recreating the experience of existing cultural heritage, as in (approximations of) virtual reality. It is hard to differentiate this branch from the core contribution of digital heritage which is storing the heritage data digitally. Parsinejad et al. developed two techniques for Digital Twinning of the architectural assets and representation of the physical assets virtually in the museum context. Two techniques are hand recording and digital recording and both have challenges in adoption and implementation of Digital Twin as a revolutionary concept. == Digital heritage stewardship == Digital heritage stewardship is a form of digital curation which is modeled after collaborative curation. Digital heritage stewardship means stepping away from typical curatorial practices (e.g. discovering, arranging, and sharing information, material, and/or content) in favor of practices which allow its stakeholders the opportunity to contribute historical, political, and social context and culture. The collaborative practice encourages the creation, engagement, and maintena
Read more →
HTTP cookie

An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small block of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session. Cookies serve useful and sometimes essential functions on the web. They enable web servers to store stateful information (such as items added in the shopping cart in an online store) on the user's device or to track the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past). They can also be used to save information that the user previously entered into form fields, such as names, addresses, passwords, and payment card numbers for subsequent use. Authentication cookies are commonly used by web servers to authenticate that a user is logged in, and with which account they are logged in. Without the cookie, users would need to authenticate themselves by logging in on each page containing sensitive information that they wish to access. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by an attacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting and cross-site request forgery for examples). Tracking cookies, and especially third-party tracking cookies, are commonly used as ways to compile long-term records of individuals' browsing histories — a potential privacy concern that prompted European and U.S. lawmakers to take action in 2011. European law requires that all websites targeting European Union member states gain "informed consent" from users before storing non-essential cookies on their device. == Background == === Origin of the name === The term cookie was coined by web-browser programmer Lou Montulli. It was derived from the term magic cookie, which is a packet of data a program receives and sends back unchanged, used by Unix programmers. === History === Magic cookies were already used in computing when computer programmer Lou Montulli had the idea of using them in web communications in June 1994. At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for MCI. Vint Cerf and John Klensin represented MCI in technical discussions with Netscape Communications. MCI did not want its servers to have to retain partial transaction states, which led them to ask Netscape to find a way to store that state in each user's computer instead. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart. Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on 13 October 1994, supported cookies. The first use of cookies (out of the labs) was checking whether visitors to the Netscape website had already visited the site. Montulli applied for a patent for the cookie technology in 1995, which was granted in 1998. Support for cookies was integrated with Internet Explorer in version 2, released in October 1995. The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of their presence. The public learned about cookies after the Financial Times published an article about them on 12 February 1996. In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997. The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the Internet Engineering Task Force (IETF) was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by Brian Behlendorf and David Kristol respectively. But the group, headed by Kristol himself and Lou Montulli, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default. At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000. RFC 2965 added a Set-Cookie2 header field, which informally came to be called "RFC 2965-style cookies" as opposed to the original Set-Cookie header field which was called "Netscape-style cookies". Set-Cookie2 was seldom used, however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world. No modern browser recognizes the Set-Cookie2 header field. == Terminology == === Session cookie === A session cookie (also known as an in-memory cookie, transient cookie or non-persistent cookie) exists only in temporary memory while the user navigates a website. Session cookies expire or are deleted when the user closes the web browser. Session cookies are identified by the browser by the absence of an expiration date assigned to them. === Persistent cookie === A persistent cookie expires at a specific date or after a specific length of time. For the persistent cookie's lifespan set by its creator, its information will be transmitted to the server every time the user visits the website that it belongs to, or every time the user views a resource belonging to that website from another website (such as an advertisement). For this reason, persistent cookies are sometimes referred to as tracking cookies because they can be used by advertisers to record information about a user's web browsing habits over an extended period of time. Persistent cookies are also used for reasons such as keeping users logged into their accounts on websites, to avoid re-entering login credentials at every visit. (See § Uses, below.) === Secure cookie === A secure cookie can only be transmitted over an encrypted connection (i.e. HTTPS). They cannot be transmitted over unencrypted connections (i.e. HTTP). This makes the cookie less likely to be exposed to cookie theft via eavesdropping. A cookie is made secure by adding the Secure flag to the cookie. === Http-only cookie === An http-only cookie cannot be accessed by client-side APIs, such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS). However, the cookie remains vulnerable to cross-site tracing (XST) and cross-site request forgery (CSRF) attacks. A cookie is given this characteristic by adding the HttpOnly flag to the cookie. === Same-site cookie === In 2016 Google Chrome version 51 introduced a new kind of cookie with attribute SameSite with possible values of Strict, Lax or None. With attribute SameSite=Strict, the browsers would only send cookies to a target domain that is the same as the origin domain. This would effectively mitigate cross-site request forgery (CSRF) attacks. With SameSite=Lax, browsers would send cookies with requests to a target domain even it is different from the origin domain, but only for safe requests such as GET (POST is unsafe) and not third-party cookies (inside iframe). Attribute SameSite=None would allow third-party (cross-site) cookies, however, most browsers require secure attribute on SameSite=None cookies. The Same-site cookie is incorporated into a new RFC draft for "Cookies: HTTP State Management Mechanism" to update RFC 6265 (if approved). Chrome, Firefox, and Edge started to support Same-site cookies. The key of rollout is the treatment of existing cookies without the SameSite attribute defined, Chrome has been treating those existing cookies as if SameSite=None, this would let all website/applications run as before. Google intended to change that default to SameSite=Lax in Chrome 80 planned to be released in February 2020, but due to potential for breakage of those applications/websites that rely on third-party/cross-site cookies and COVID-19 circumstances, Google postponed this change to Chrome 84. === Supercookie === A supercookie is a cookie with an origin of a top-level domain (such as .com) or a public suffix (such as .co.uk). Ordinary cookies, by contrast, have an origin of a specific domain name, such as ex
Read more →
BulSemCor

The Bulgarian Sense-annotated Corpus (BulSemCor) (Bulgarian: Български семантично анотиран корпус (БулСемКор)) is a structured corpus of Bulgarian texts in which each lexical item is assigned a sense tag. BulSemCor was created by the Department of Computational Linguistics at the Institute for Bulgarian Language of the Bulgarian Academy of Sciences. == Structure == BulSemCor was created as part of a nationally funded project titled "BulNet – A lexico-semantic network for the Bulgarian Language" (2005–2010). It follows the general methodology of SemCor combined with some specific principles. The corpus for annotation consists of 101,791 tokens covering an excerpt from the Bulgarian "Brown" Corpus modelled on the Brown Corpus.Francis Kucera An important feature of BulSemCor is that the samples are selected using heuristics that provide optimal coverage of ambiguous lexis. BulSemCor is manually sense-annotated according to the Bulgarian WordNet. Its size is comparable to that of other contemporary semantically annotated corpora or pool of acceptable linguistic components. The semantic annotation consists in associating each lexical item in the corpus with exactly one synonym set (synset) in the Bulgarian WordNet that best describes its sense in the particular context. The selection of the best match among the suggested candidates is based on a set of procedures, such as the other synset members, the synset gloss (explanatory definition) and the position of a given candidate in the WordNet structure. == Scale == The number of annotated tokens is 99,480 (the difference in the number of tokens compared to the initial corpus is due to the fact that some of them are not linguistic items). The simple word count is 86,842 and multiword expressions (MWE) are 5,797 (12,638 tokens). == Specific features == All words in BulSemCor are assigned a sense, while according to established practice only simple content words or content word classes (typically nouns and verbs) are annotated. Since 2000 the development of language resources, has broadened to include annotation of function words and multiword expressions covering particular senses or types of words and expressions. In this respect, BulSemCor's annotation is more exhaustive and hence provides greater opportunities for linguistic observations and non-linear programming (NLP) applications. Annotated items inherit the linguistic information associated with the corresponding synset, which along with morphological and semantic tags may include annotation on one or more of the following additional levels: Partial information about the syntactic structure of MWE types – particularly, information about syntactic heads and their dependents; Information about the category of the named entities – names, locations, organisations, dates, numbers, etc.; Information about the taxonomic category of adverbs, such as time, place, manner, degree, quantity, etc.; Information about the type of the syntactic relationships – coordination or subordination – expressed by conjunctions; Information about the original part-of-speech of substantivised words (non-nouns that act as nouns in a particular context); Stylistic/register, grammatical and other information about synsets or individual synset members;
Read more →
Magnetoquasistatic field

A magnetoquasistatic field is a class of electromagnetic field in which a slowly oscillating magnetic field is dominant. A magnetoquasistatic field is typically generated by low-frequency induction from a magnetic dipole or a current loop. The magnetic near-field of such an emitter behaves differently from the more commonly used far-field electromagnetic radiation. At low frequencies the rate of change of the instantaneous field strength with each cycle is relatively slow, giving rise to the name "magneto-quasistatic". The near field or quasistatic region typically extends no more than a wavelength from the antenna, and within this region the electric and magnetic fields are approximately decoupled. Weakly conducting non-magnetic bodies, including the human body and many mineral rocks, are effectively transparent to magnetoquasistatic fields, allowing for the transmission and reception of signals through such obstacles. Also, long-wavelength (i.e. low-frequency) signals are better able to propagate round corners than shorter-wave signals. Communication therefore need not be line-of-sight. The communication range of such signals depends on both the wavelength and the electromagnetic properties of the intervening medium at the chosen frequency, and is typically limited to a few tens of meters. == Physical principles == The laws of primary interest are Ampère's circuital law (with the displacement current density neglected) and the magnetic flux continuity law. These laws have associated with them continuity conditions at interfaces. In the absence of magnetizable materials, these laws determine the magnetic field intensity H given its source, the current density J. H is not everywhere irrotational. However, it is solenoidal everywhere. == Equipment design == A typical antenna comprises a 50-turn coil around a polyoxymethylene tube with diameter 16.5 cm, driven by a class E oscillator circuit. Such a device is readily portable when powered by batteries. Similarly, a typical receiver consist of an active receiving loop with diameter of one meter, an ultra-low-noise amplifier, and a band-pass filter. In operation the oscillator drives current through the transmitting loop to create an oscillating magnetic field. This field induces a voltage in the receiving loop, which is then amplified. Because the quasistatic region is defined within one wavelength of the electromagnetic source, emitters are limited to a frequency range between about 1 kHz and 1 MHz. Reducing the oscillating frequency increases the wavelength and hence the range of the quasistatic region, but reduces the induced voltage in the receiving loops which worsens the signal-to-noise ratio. In experiments carried out by the Carnegie Institute of Technology, the maximum range reported by was 50 meters. == Applications == === Resonant inductive coupling === In resonant coupling, the source and receiver are tuned to resonate at the same frequency and are given similar impedances. This allows power as well as information to flow from the source to the receiver. Such coupling via the magnetoquasistatic field is called resonant inductive coupling and can be used for wireless energy transfer. Applications include induction cooking, induction charging of batteries and some kinds of RFID tag. === Communications === Conventional electromagnetic communication signals cannot pass through the ground. Most mineral rock is neither electrically conducting nor magnetic, allowing magnetic fields to penetrate. Magnetoquasistatic systems have been successfully used for underground wireless communication, both surface-to-underground and between underground parties. At extremely low frequencies, below about 1 kHz, the wavelength is long enough for long-distance communication, although at a slow data rate. Such systems have been installed in submarines, with the local antenna comprising a wire up to several kilometers in length and trailed behind the vessel when at or near the surface. === Position and orientation tracking === Wireless position tracking is being increasingly used in applications such as navigation, security, and asset tracking. Conventional position tracking devices use high frequencies or microwaves, including global positioning systems (GPS), ultra-wide band (UWB) systems, and radio frequency identification systems (RFID), but these systems can easily be blocked by obstacles in their path. Magnetoquasistatic positioning takes advantage of the fact that the fields are largely undisturbed when in the presence of human beings and physical structures, and can be used for both position and orientation tracking for ranges up to 50 meters. To accurately determine the orientation and position of a dipole/emitter, allowance must be made not only for the field pattern generated by the emitter, but also for the eddy-currents they induce in the earth, which create secondary fields detectable by the receivers. By using complex image theory to correct this field generation from earth, and by using frequencies on the order of a few hundred kilohertz to obtain the required signal-to-noise ratio (SNR), it is possible to analyze the position of the dipole through azimuthal orientation, θ {\displaystyle \theta } , and inclination orientation, ϕ {\displaystyle \phi } . A Disney research team has used this technology to effectively determine the position and orientation of an American football, something not traceable through conventional wave propagation techniques due to human body obstruction. They inserted an oscillator-driven coil, around the diameter of the center of the ball, to generate the magnetoquasistatic field. The signal was able to pass undisturbed through multiple players.
Read more →
MADI

Multichannel Audio Digital Interface (MADI) standardized as AES10 by the Audio Engineering Society (AES) defines the data format and electrical characteristics of an interface that carries multiple channels of digital audio. The AES first documented the MADI standard in AES10-1991 and updated it in AES10-2003 and AES10-2008. The MADI standard includes a bit-level description and has features in common with the two-channel AES3 interface. MADI supports serial digital transmission over coaxial cable or fibre-optic lines of 28, 56, 32, or 64 channels; and sampling rates to 96 kHz and beyond with an audio bit depth of up to 24 bits per channel. Like AES3 and ADAT Lightpipe, it is a unidirectional interface from one sender to one receiver. == Development and applications == MADI was developed by AMS Neve, Solid State Logic, Sony and Mitsubishi and is widely used in the audio industry, especially in the professional audio sector. It provides advantages over other audio digital interface protocols and standards such as AES3, ADAT Lightpipe, TDIF (Tascam Digital Interface), and S/PDIF (Sony/Philips Digital Interface). These advantages include: Support for a greater number of channels per line Use of coaxial and optical fiber media that support transmission of audio signals over 100 meters, up to 3000 meters over multi-mode and 40,000 meters over single-mode optical fiber The original specification (AES10-1991) defined the MADI link as a 56-channel transport for linking large-format mixing consoles to digital multitrack recording devices. Large broadcast studios also adopted it for routing multi-channel audio throughout their facilities. The 2003 revision (AES10-2003) adds a 64-channel capability by removing varispeed operation and supports 96 kHz sampling frequency with reduced channel capacity. The latest AES10-2008 standard includes minor clarifications and updates to correspond to the current AES3 standard. Audio over Ethernet of various types is the primary alternative to MADI for transport of many channels of professional digital audio. == Transmission format == MADI links use a transmission format similar to Fiber Distributed Data Interface (FDDI) networking. Since MADI is most often transmitted on copper links via 75-ohm coaxial cables, it more closely compares to the FDDI specification for copper-based links, called CDDI. AES10-2003 recommends using BNC connectors with coaxial cables and SC connectors with optic fibers. MADI over fibre can support a range of up to 2 km. The basic data rate is 100 Mbit/s of data using 4B5B encoding to produce a 125 MHz physical baud rate. Unlike AES3, this clock is not synchronized to the audio sample rate, and the audio data payload is padded using JK sync symbols. Sync symbols may be inserted at any subframe boundary, and must occur at least once per frame. Though the standard disassociates the transmission clock from the audio sample rate, and thus requires a separate word clock connection to maintain synchronization, some vendors do give the option of locking to parts of the transmission timing information for purposes of deriving a word clock. The audio data is almost identical to the AES3 payload, though with more channels. Rather than letters, MADI assigns channel numbers from 0–63. Frame synchronization is provided by sync symbols outside the data itself, rather than an embedded preamble sequence, and the first four time slots of each sub-channel are encoded as normal data, used for sub-channel identification: Bit 0: Set to 1 to mark channel 0, the first channel in each frame Bit 1: Set to 1 to indicate that this channel is active (contains interesting data) Bit 2: notA/B channel marker, used to mark left (0) and right (1) channels. Generally, even channels are A and odd channels are B. Bit 3: Set to 1 to mark the beginning of a 192-sample data block == Sampling frequency == The original AES10-1991 specification allowed 56 channels at sample rates from 32 to 48 kHz with an additional vari-speed range of ± 12.5%. This leads to a total range of 28 to 54 kHz. At the highest frequency, this produces a total of 56 × 32 × 54 = 96768 kbit/s, leaving 3.232% of the channel for synchronization marks and transmit clock error. The 2003 revision specifies different relations between sampling frequency and number of channels. 32 kHz to 48 kHz ± 12.5%, 56 channels; 32 kHz to 48 kHz nominal, 64 channels; 64 kHz to 96 kHz ± 12.5%, 28 channels. With a 48 kHz sampling frequency, 64 channels take 64 × 32 × 48000 = 98.304 Mbit/s. Adding the minimum 8 × 58 kbit/s of framing produces 98688 bit/s, leaving 1.312% free for timing variation and other overhead. Both versions of the standard accommodate higher sampling frequencies (for example, 96 kHz or 192 kHz) by using two or more channels per audio sample on the link.
Read more →