Recherche avancée

Sur d’autres sites (5196)

• CD-R Read Speed Experiments

  21 mai 2011, par Multimedia Mike — Science Projects, Sega Dreamcast

  I want to know how fast I can really read data from a CD-R. Pursuant to my previous musings on this subject, I was informed that it is inadequate to profile reading just any file from a CD-R since data might be read faster or slower depending on whether the data is closer to the inside or the outside of the disc.

  Conclusion / Executive Summary
  It is 100% true that reading data from the outside of a CD-R is faster than reading data from the inside. Read on if you care to know the details of how I arrived at this conclusion, and to find out just how much speed advantage there is to reading from the outside rather than the inside.

  Science Project Outline

  • Create some sample CD-Rs with various properties
  • Get a variety of optical drives
  • Write a custom program that profiles the read speed

  Creating The Test Media
  It’s my understanding that not all CD-Rs are created equal. Fortunately, I have 3 spindles of media handy : Some plain-looking Memorex discs, some rather flamboyant Maxell discs, and those 80mm TDK discs :

  
  
  

  My approach for burning is to create a single file to be burned into a standard ISO-9660 filesystem. The size of the file will be the advertised length of the CD-R minus 1 megabyte for overhead— so, 699 MB for the 120mm discs, 209 MB for the 80mm disc. The file will contain a repeating sequence of 0..0xFF bytes.

  Profiling
  I don’t want to leave this to the vagaries of any filesystem handling layer so I will conduct this experiment at the sector level. Profiling program outline :

  • Read the CD-ROM TOC and get the number of sectors that comprise the data track
  • Profile reading the first 20 MB of sectors
  • Profile reading 20 MB of sectors in the middle of the track
  • Profile reading the last 20 MB of sectors

  Unfortunately, I couldn’t figure out the raw sector reading on modern Linux incarnations (which is annoying since I remember it being pretty straightforward years ago). So I left it to the filesystem after all. New algorithm :

  • Open the single, large file on the CD-R and query the file length
  • Profile reading the first 20 MB of data, 512 kbytes at a time
  • Profile reading 20 MB of sectors in the middle of the track (starting from filesize / 2 - 10 MB), 512 kbytes at a time
  • Profile reading the last 20 MB of sectors (starting from filesize - 20MB), 512 kbytes at a time

  Empirical Data
  I tested the program in Linux using an LG Slim external multi-drive (seen at the top of the pile in this post) and one of my Sega Dreamcast units. I gathered the median value of 3 runs for each area (inner, middle, and outer). I also conducted a buffer flush in between Linux runs (as root : 'sync; echo 3 > /proc/sys/vm/drop_caches').

  LG Slim external multi-drive (reading from inner, middle, and outer areas in kbytes/sec) :

  • TDK-80mm : 721, 897, 1048
  • Memorex-120mm : 1601, 2805, 3623
  • Maxell-120mm : 1660, 2806, 3624

  So the 120mm discs can range from about 10.5X all the way up to a full 24X on this drive. For whatever reason, the 80mm disc fares a bit worse — even at the inner track — with a range of 4.8X - 7X.

  Sega Dreamcast (reading from inner, middle, and outer areas in kbytes/sec) :

  • TDK-80mm : 502, 632, 749
  • Memorex-120mm : 499, 889, 1143
  • Maxell-120mm : 500, 890, 1156

  It’s interesting that the 80mm disc performed comparably to the 120mm discs in the Dreamcast, in contrast to the LG Slim drive. Also, the results are consistent with my previous profiling experiments, which largely only touched the inner area. The read speeds range from 3.3X - 7.7X. The middle of a 120mm disc reads at about 6X.

  Implications
  A few thoughts regarding these results :

  • Since the very definition of 1X is the minimum speed necessary to stream data from an audio CD, then presumably, original 1X CD-ROM drives would have needed to be capable of reading 1X from the inner area. I wonder what the max read speed at the outer edges was ? It’s unlikely I would be able to get a 1X drive working easily in this day and age since the earliest CD-ROM drives required custom controllers.
  • I think 24X is the max rated read speed for CD-Rs, at least for this drive. This implies that the marketing literature only cites the best possible numbers. I guess this is no surprise, similar to how monitors and TVs have always been measured by their diagonal dimension.
  • Given this data, how do you engineer an ISO-9660 filesystem image so that the timing-sensitive multimedia files live on the outermost track ? In the Dreamcast case, if you can guarantee your FMV files will live somewhere between the middle and the end of the disc, you should be able to count on a bitrate of at least 900 kbytes/sec.

  Source Code
  Here is the program I wrote for profiling. Note that the filename is hardcoded (#define FILENAME). Compiling for Linux is a simple 'gcc -Wall profile-cdr.c -o profile-cdr'. Compiling for Dreamcast is performed in the standard KallistiOS manner (people skilled in the art already know what they need to know) ; the only variation is to compile with the '-D_arch_dreamcast' flag, which the default KOS environment adds anyway.

  PLAIN TEXT

  C :

  1. #ifdef _arch_dreamcast
  2.   #include <kos .h>
  3.  
  4.   /* map I/O functions to their KOS equivalents */
  5.   #define open fs_open
  6.   #define lseek fs_seek
  7.   #define read fs_read
  8.   #define close fs_close
  9.  
  10.   #define FILENAME "/cd/bigfile"
  11. #else
  12.   #include <stdio .h>
  13.   #include <sys /types.h>
  14.   #include </sys><sys /stat.h>
  15.   #include </sys><sys /time.h>
  16.   #include <fcntl .h>
  17.   #include <unistd .h>
  18.  
  19.   #define FILENAME "/media/Full disc/bigfile"
  20. #endif
  21.  
  22. /* Get a current absolute millisecond count ; it doesn’t have to be in
  23. * reference to anything special. */
  24. unsigned int get_current_milliseconds()
  25. {
  26. #ifdef _arch_dreamcast
  27.   return timer_ms_gettime64() ;
  28. #else
  29.   struct timeval tv ;
  30.   gettimeofday(&tv, NULL) ;
  31.   return tv.tv_sec * 1000 + tv.tv_usec / 1000 ;
  32. #endif
  33. }
  34.  
  35. #define READ_SIZE (20 * 1024 * 1024)
  36. #define READ_BUFFER_SIZE (512 * 1024)
  37.  
  38. int main()
  39. {
  40.   int i, j ;
  41.   int fd ;
  42.   char read_buffer[READ_BUFFER_SIZE] ;
  43.   off_t filesize ;
  44.   unsigned int start_time, end_time ;
  45.  
  46.   fd = open(FILENAME, O_RDONLY) ;
  47.   if (fd == -1)
  48.   {
  49.     printf("could not open %s\n", FILENAME) ;
  50.     return 1 ;
  51.   }
  52.   filesize = lseek(fd, 0, SEEK_END) ;
  53.  
  54.   for (i = 0 ; i <3 ; i++)
  55.   {
  56.     if (i == 0)
  57.     {
  58.       printf("reading inner 20 MB...\n") ;
  59.       lseek(fd, 0, SEEK_SET) ;
  60.     }
  61.     else if (i == 1)
  62.     {
  63.       printf("reading middle 20 MB...\n") ;
  64.       lseek(fd, (filesize / 2) - (READ_SIZE / 2), SEEK_SET) ;
  65.     }
  66.     else
  67.     {
  68.       printf("reading outer 20 MB...\n") ;
  69.       lseek(fd, filesize - READ_SIZE, SEEK_SET) ;
  70.     }
  71.     /* read 20 MB ; 40 chunks of 1/2 MB */
  72.     start_time = get_current_milliseconds() ;
  73.     for (j = 0 ; j <(READ_SIZE / READ_BUFFER_SIZE) ; j++)
  74.       if (read(fd, read_buffer, READ_BUFFER_SIZE) != READ_BUFFER_SIZE)
  75.       {
  76.         printf("read error\n") ;
  77.         break ;
  78.       }
  79.     end_time = get_current_milliseconds() ;
  80.     printf("%d - %d = %d ms => %d kbytes/sec\n",
  81.       end_time, start_time, end_time - start_time,
  82.       READ_SIZE / (end_time - start_time)) ;
  83.   }
  84.  
  85.   close(fd) ;
  86.  
  87.   return 0 ;
  88. }

• iOS 17’s Impact on Marketing : Navigating Privacy Changes

  22 septembre 2023, par Erin — Analytics Tips, Marketing

  In the ever-evolving landscape of digital marketing, staying up-to-date with the latest changes is paramount. One such significant change came on 18 September 2023, in the form of iOS 17, Apple’s latest operating system update. With iOS 17, Apple has introduced new privacy features that are set to have a profound impact on marketers and how they track and analyse user behaviour. 

  In this blog, we will explore what iOS 17 is, how it affects tracking, which tracking parameters are impacted, what remains unaffected, and most importantly, how marketers can future-proof their campaign tracking URLs.

  What is iOS 17 ?

  iOS 17 is the latest update to Apple’s mobile operating system, used on millions of iPhones worldwide. While iOS updates often bring new features and improvements, iOS 17 has made waves in the digital marketing community due to its emphasis on user privacy.

  How does iOS 17 affect tracking ?

  One of the key features of iOS 17 that concerns marketers is its impact on tracking. Apple’s new update aims to enhance user privacy by limiting the information that can be tracked and collected by third-party entities, particularly through query parameters in URLs. This means that certain tracking mechanisms that marketers have relied on for years are now rendered ineffective on iOS 17 devices.

  Campaign tracking URLs, also known as tracking parameters or UTM parameters, are special codes added to the end of URLs. They are used by marketers to track various aspects of a user’s interaction with a digital marketing campaign. These parameters provide valuable data, such as the source of traffic, the medium through which users arrived and specific campaign details.

  For example, with Matomo (mtm) tracking parameters, a campaign tracking URL might look like this :

  https://www.example.com/products/example_product?mtm_campaign=summer-sale

  

  Understanding the impact of iOS 17 on campaign tracking URLs is essential for marketers who rely on this data to measure the effectiveness of their marketing campaigns.

  Which campaign tracking parameters are affected by iOS 17 ?

  Several tracking parameters commonly used by marketers will no longer work as expected on iOS 17. Some of these include :

  • Facebook (fbclid) : Employed for tracking Facebook advertising campaigns. 
  • Instagram (igshid) : Used to track user interactions with Instagram ads.
  • Google Ads (gclid) : Used to track Google Ads campaigns. 
  • Twitter (twclid) : Used to track user interactions with Twitter ads. 
  • Microsoft Ads (msclkid) : Employed for tracking Microsoft Ads campaigns. 
  • Mailchimp (mc_eid) : Used by Mailchimp for email campaign tracking. 

  These changes are significant, as they disrupt many of the common tracking methods that marketers rely on to measure the effectiveness of their campaigns.

  Which campaign tracking parameters are not affected by iOS 17 ?

  While many tracking parameters have been impacted, there are still some that remain unaffected on iOS 17. However, it’s important to note that the status of these parameters might change in the future as Apple continues to prioritise user privacy. Some of the tracking parameters that are still working as of now include :

  • Matomo (mtm) : Matomo campaign tracking parameters. 
  • Google Analytics (UTMs) : Google Analytics campaign tracking parameters.
  • Pinterest (epik) : Used for tracking Pinterest campaigns. 
  • Klaviyo (_kx) : Klaviyo for email marketing tracking. 
  • TikTok (tt-) : Used for tracking TikTok ad interactions. 
  • Hubspot (hsa) : Used for tracking Hubspot campaigns. 

  While these parameters offer some reprieve for marketers, it’s essential to keep a close eye on any potential changes in their functionality as Apple continues to roll out privacy-friendly features.

  How are Matomo users impacted ?

  Fortunately, Matomo, as a leading privacy-friendly web analytics solution, remains unaffected by the changes introduced by iOS 17. Specifically :

  For Matomo users who rely on mtm or UTMs

  If you’re using Matomo or GA tracking parameters, you can rest assured that iOS 17’s changes won’t affect your tracking capabilities in Matomo.

  Attention to gclids (Google Ads) and msclkid (Bing Ads)

  If you use Google Ads or Bing Ads tracking parameters with Matomo’s Advertising Conversion Export feature for tracking, iOS 17 presents a challenge. Your gclids and msclkids may not provide the same level of tracking accuracy on Apple mobile devices. This is a critical consideration, especially if your ad campaigns target mobile users.

  To stay informed about changes in the digital marketing landscape, including updates related to iOS 17, sign up for our newsletter where we regularly provide updates and insights on adapting your tracking and marketing strategies to ensure compliance and respect user privacy.

  How to future-proof your campaign tracking

  Given the impact of iOS 17 on tracking, it’s crucial for marketers to adapt and future-proof their campaign tracking strategies. Here are some steps you can take to mitigate the affects of iOS 17 on your marketing campaigns :

  Monitor platform updates

  Expect updates from advertising and analytics platforms in response to Apple’s privacy changes. These platforms are likely to develop alternative tracking methods or adapt existing ones to comply with iOS 17’s restrictions. Stay informed about these updates and incorporate them into your tracking strategy.

  Prioritise privacy-friendly tech stacks

  In the ever-evolving digital marketing landscape, it’s crucial to prioritise privacy-friendly tech stacks. Privacy-friendly tracking tools like Matomo are essential for maintaining trust and respecting user privacy.

  Matomo ensures the privacy of your users and analytics data. When using Matomo, you retain control of your data ; nobody else does. This commitment to user privacy aligns with the changing digital marketing landscape, where privacy is taking centre stage.

  Transition from affected campaign tracking parameters

  If you’ve been using tools like Mailchimp, whose campaign tracking URLs have been affected by iOS 17, consider transitioning to the campaign tracking URL parameters of your analytics solution. Whether you choose Matomo or Google Analytics, these solutions can help you understand how your email marketing campaigns are performing.

  Focus on data privacy compliance

  Embrace data privacy compliance practices. As privacy regulations evolve, it’s essential to prioritise transparency in data collection. Ensure that your tracking methods align with privacy standards to maintain trust with your audience.

  Regularly review and adapt

  The digital marketing landscape is dynamic, and iOS 17 is just one example of how quickly things can change. Regularly review your tracking methods and adapt to new developments in the industry. Staying agile and informed is key to long-term success.

  Marketers’ path forward

  iOS 17 has reshaped mobile user privacy, challenging marketers to adapt. While some tracking parameters are affected, savvy marketers can still thrive by embracing unique tracking solutions, staying informed about platform updates, and prioritising data privacy. 

  Explore Matomo for privacy-friendly analytics and navigate this evolving landscape successfully with our 21-day free trial – no credit card required. 

• Revision 37431 : Désormais, le plugin de mutualisation fait non seulement la mise à jour de ...

  19 avril 2010, par real3t@… — Log

  Désormais, le plugin de mutualisation fait non seulement la mise à jour de SPIP, mais *aussi* la mise à jour des plugins (particulièrement utile pour passer de SPIP 2 à SPIP 2.1 avec des extensions/ )